Another bout of web services “religious war” has broken out again. We’ve been here before! This time it’s based on one funny and accurate diatribe about SOAP. The resulting frenzy in the blogosphere has yielded some quality comments, and even some declarations of victory by those who think REST is the one true way.

Amongst the furore, there were four key comments:

  1. Nelson Minar whose opinion on soap web services has to be respected states:
The deeper problem with SOAP is strong typing. WSDL accomplishes its magic via XML Schema and strongly typed messages. But strong typing is a bad choice for loosely coupled distributed systems. The moment you need to change anything, the type signature changes and all the clients that were built to your earlier protocol spec break. And I don't just mean major semantic changes break things, but cosmetic things like accepting a 64 bit int where you use used to only accept 32 bit ints, or making a parameter optional. SOAP, in practice, is incredibly brittle. If you're building a web service for the world to use, you need to make it flexible and loose and a bit sloppy. Strong typing is the wrong choice. 1. This is backed up by [Joe Gregorio](http://bitworking.org/news/Nelson_Minar_on_SOAP):
... if you don't have control of both ends of the wire then loosely typed documents beat strongly typed data-structure serializations. 1. And finally, Sam Ruby [pointed out](http://www.intertwingly.net/blog/2006/11/17/The-H-stands-for-Hyper) that it's just much easier to handle problems with developing restful applications. He also makes the following throw away:
In addition to all the architectural benefits of REST, as well as all the pragmatic experience the web has built up over time with caching and intermediaries? benefits and experience that WS-* forsakes ... 1. [Gunnar Peterson](http://1raindrop.typepad.com/1_raindrop/2006/12/rest_security_o.html) makes the point that it's not just about unsecured applications ([via Sam Ruby](http://www.intertwingly.net/blog/2006/12/01/Equal-Time)):
... But if you are going to say that REST is so much simpler than SOAP then you should compare REST with HMAC, et. al. to the sorts of encryption and signature services WS-Security gives you and then see how much simpler is.

Which brings me to me why I wanted to say something. It’s just not as simple as some might say, and even Roy Fielding didn’t claim that REST solved all the problems in the world! I wonder how many of the vocieferous RESTful advocates have actually read his thesis?

Some choice quotes:

Some architectural styles are often portrayed as ?silver bullet? solutions for all forms of software. However, a good designer should select a style that matches the needs of the particular problem being solved. Choosing the right architectural style for a network-based application requires an understanding of the problem domain and thereby the communication needs of the application, an awareness of the variety of architectural styles and the particular concerns they address, and the ability to anticipate the sensitivity of each interaction style to the characteristics of network-based communication.
The REST interface is designed to be efficient for large- grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.
REST is not intended to capture all possible uses of the Web protocol standards. There are applications of HTTP and URI that do not match the application model of a distributed hypermedia system.

So where do I stand on all this? In practice, some of the applications of this stuff are simply not “distributed hypermedia applications” (which is what REST was designed for). Some of them really are distributed object activities (the OGC things), and some of the assumptions of REST are violated in the grid world - for example, I’m not terribly interested in automatic caching when my data objects are huge -10 GB+-, and write performance is as important is read performance, and latency doesn’t matter because machines are doing the work. (I’m happy to provide quotes from Fielding’s thesis where he lists these things as reasons for REST!)

But we don’t just do big science data moving at the BADC. In trying to get my thoughts together on this, I came up with the following classification of communities based on what they are trying to do:

     Strong Typing    Weak Typing  
  Tight Coupling    Grid (Implicit1 Typing)    "Secured"2 Web Applications  
  Loose Coupling    OGC (Explicit3 Typing)    "Web 2" & Mash-ups  


where

  1. Implicit Typing: Nearly all grid applications are file based at the “usage” point or use OGSA/DAI. Either way the applications are tightly coupled to an implicit knowledge of exactly what the contents of the data resources are - the semantic content of the data resources is known to the (human) builder of workflows. I’m not aware of any real attempt to do late binding of services based on the semantic content1 of the data resources.
  2. Secured: Here I’m implying more than just the use of https as a transport mechanism. There is usage of sophisticated AAA mechanisms which include role-based access control - but in the final analysis the actual processes or transactions are relatively loosely coupled.
  3. Explicit: The OpenGeospatial Community has built very sophisticated mechanisms of building detailed descriptions of computational objects (features) which match onto the features of the real world. These objects have detailed structures, multiple attributes, maybe decomposable, and have implicit interfaces which afford behaviour.

(As an aside, note that in general the tightly coupled systems have strong security. Also that recent work within the OGC community has been building SOAP bindings and strong security into the OGC web service paradigm. It’s unfortunate that that work is being done in the context of a project known as GeoDRM … which has all sorts of bad connotations … mostly it’s about GeoAAA2, not DRM!).

All the really good arguments for REST lie in the bottom right corner of the table … and to be fair, its also where the majority of web usage should lie too!

The reality is that the availability of tooling plus the type of task makes decisions for me! We’re building things that are a mash-up of web-services (which we secure using WS-security) and plain old XML type services (which we secure using gatekeepers that exploit WS-*). We do do some REST things. We’re not using much “pure” grid tooling, because the python tooling isn’t mature enough yet. But we will.

So there is no silver bullet right now! For me, any sort of fundamentalism sucks. The final word belongs to Nelson Minar:

Truly, none of this protocol fiddling matters. Just do something that works.

(Update, 4th Dec. Aaargh: the material in italics above somehow got lost presumably because I missed the last seconds of my wireless time in the great southern blackspot.)

trackbacks (2)

Service Orientated Architecture - Two Years On! (from “Bryan’s Blog” on (on Thursday 07 December, 2006))

I’ve been blogging for slightly over two years. After I wrote my SOA article earlier today, I realised that my second ever blog post was on SOA. Then, as now, I had been reading Savas’s blog. …

Whither service descriptions (from “Bryan’s Blog” on (on Tuesday 22 January, 2008))

… there is a long tail of activities for which the abilities of web services to open up interoperabilty is being hindered by the difficulty in both service and data description …

comments (2)

bill@dehora.net (on Monday 04 December, 2006)

“by those who think REST is the one true way.”

Not me. You need to read what I said in the context. It started out with roughly, REST is a tinkertoy, and worked its way to here.

Bryan (on Wednesday 06 December, 2006)

Sorry Bill … but it’s quite hard to get all your posts in context. Especially that one :-)

  1. Where I’m meaning semantic content at the level of detail exposed by, for example, GML Application Schema ↩

  2. Authentication, Authorisation, Access ↩