REST or not to REST

REST (Representational State Transfer) is a very interesting style of service architecture; this morning, I and another architect, were looking at the pro's and con's of REST vs. Soap and WSDL. We also looked into the possibility of combining the two worlds using REST with standard Soap as the payload, gaining the Uri loveliness of REST and the structure and standards of Soap. The upshot for me was that REST is definitely a viable and compelling technology, my thinking is if your service is simple then keep it simple with something like REST - if you need a highly structured secure service then Soap and WSDL would probably make more sense.

One other point of interest was the obvious tight coupling between REST and HTTP i.e. the service implementation style and the protocol; there is no such constraint with Soap and WSDL. However, this is nicely exploited with RESTful services in that they use the verbs defined in HTTP to state the intent of the message e.g. POST == Create, GET == Read, PUT == Update and DELETE = Delete. The intent then does not need to be inferred, in the worst case, or explicit in the name of the call, meaning I can operate just on the named resource e.g. Customer or PurchaseOrder etc. clearly and cleanly:

The intent here is to change the Postcode for a Customer entity - I like how clean that is, the equivalent in Soap would be much more verbose and the intent would be specified by the SOAPAction and/or inferred from the wrapped type e.g. ChangeCustomerAddressRequest. There are some obvious problems with the REST approach in relation to enterprise systems but you cannot argue with the simplicity and when it come to just getting things done, I like it.

My biggest fear with employing the HTTP verbs is that most firewalls are not verb friendly - in that they only allow POST and GET, where POST basically means INVOKE and the intent for the call is buried somewhere deep in the payload. Which probably means that an alternative header, ala SOAPAction and the GDATA X-HTTP-Method-Override approach. I'm really interested to see how this plays out over time - will the verb usage just go away or will there be more widespread support for the verbs?

This, however, is not enough of an issue to scare me away but I'm also unlikely to the verbs other then POST and GET, but jump straight to the alternate X-Header approach to save the thinking time and the clock cycles (maybe not even bother with GET!). The core reason this issue does not make we want to run a mile is that the power of REST for me is in the simplicity of the "Uri" approach that RESTful services have; this is powerful and very compelling.

1 comment:

John Powell said...

Yeh, it’s quite easy to hand crank a couple of features using REST, as soon as you start looking at other aspects like security, audit, extra meta and self describing contracts you invariably have to include the protocol in your thoughts and bake your own discovery language. Maybe it’s meant for well known interfaces like RSS, ATOM and smtp (oooh I could get a pasting for that) where there is no need for a interface description. Nice article!