SOAP versus REST(ful) HTTP

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.

blog comments powered by Disqus