A few weeks ago there was a question about REST on the SOA-BPM
Enterprise Methodology Group about The End Of The Road For Web
Services. I posted the following reply to the list. It’s my view on
the whole SOAP versus REST discussion. (short summary: somebody decided
to fix http for rpc usage, without understanding that http wasn’t
broken).
In my opinion, SOAP was invented because people didn’t understand
what they had with HTTP. They thought it was for documents, but
it’s actually a great protocol for distributed computing. It’s actually
the most succesful, scalable, loosely coupled distributed
computing protocol ever invented.
SOAP threw away most of the features of HTTP, and replaced them with one
HTTP method (POST), and put all the metadata into the SOAP envelope,
even if good HTTP alternatives are available. Typical “not invented
here” syndrom.
REST(ful http) just advocates that HTTP is good enough and doesn’t need
to be replaced with something else. HTTP is a 20 year old
proven, scalable way of doing distributed computing, SOAP replaced it 10
years later with an XML corba implementation on top of HTTP. Why?
Regarding the points mentioned above
- Contract first: http methods are fixed (GET, PUT, POST,
DELETE, OPTIONS, HEAD, etc), and datatypes are defined by mime-type,
so the contract is clear. If you connect to a webserver to get an
html page you know the contract: http methods + html datatype.
- Documentation: no need for something new, HTTP has great support
for documentation, it can serve all the documents you need. A
service can have can service data and documentations, it’s already
built in.
- Automatic discovery: HTTP is very discoverable, because
every resource/service has a url and every resource can link to
other resources. Google has proven that HTTP/REST is extremely
discoverable. Once you know the url of a resource, you can do an
OPTIONS method to the resource and it will tell you which HTTP
methods are supported. It will also tell you which datatypes are
supported (mimetypes), so you can generate java code for xml
datatypes if these are supported.
- Security: you have basic authentication, and
encryption. Additionaly, a lot of effort is currently being put into
adding advanced security into http, instead of on top of it. Http
header properties can be used for oauth and openid.
- Transactions: most people agree that this is not really something
to be desired in large scale distributed apps, they create
tightly coupled relations, compensation is a better strategy.
Added bonus for using plain http:
- endpoint virtualization using commodity webservers using
mod_proxy, proven cheap technology.
- caching of read-only calls (GET) using mod_cache in
commodity webservers. This makes http extremely scalable.
- multiple dataformats with dataformat negotiation: you can
specify what format you prefer, the service can offer multiple
formats: xml, json, pdf, ms-word, etc. The client can select the
dataformat best suited (json in the browser, xml for app-to-app
communication).
- language negotiation: you can specify what language you prefer,
and the service will return data in the language specified if
available
- standardized error codes: HTTP has a large number of
standardized error coded (eg 404, 500, etc). No need to invent
service specific error codes. This increases loose coupling, and
helps with reuse of code.
- Usability: because the interface is stable, a lot of tools
are available (wget, curl, browsers), no need for code generation.
Easier to use for developers.
- Cannonical data model: there’s less need for a canonical data
model. Instead of agreeing on an xml format for a datatype so all
parties understand it, services can just link to to data.
HTTP is a beautiful protocol, it’s a shame it’s not well understood.