UWS as a REST protocol

Matthew Graham mjg at cacr.caltech.edu
Tue Feb 27 11:15:20 PST 2007


Whilst it may at first look as though we are talking about "using URLs 
in place of SOAP calls" here, this is not the case: we are actually 
specifically addressing two different ways of exposing *web* services 
(and not generic services). *Web* services means that standardization 
and XML are axiomatic and the different architectural styles we are 
discussing impose different standardizations. SOAP focuses on a 
standardized messaging framework traditionally tied to an RPC-like 
service interface whereas REST is about resources identifiable by nouns 
*and* a standardized set of finite operations which map to the HTTP methods.

Reworking Roy's example: 
http://blabla.edu?service=cutout&POS=301,22&recipe=bombayduck (which 
would never be a *web* service endpoint) - a SOAP-based *web* service 
version of this would send a message like:


to the service endpoint of, say, http://blabla.edu/services to retrieve 
the recipe.

The REST alternative is to send an HTTP GET request to the service 
endpoint of http://blabla.edu/cutout/301/22/bombayduck.

Suppose we now want to update the recipe: with SOAP, we might have to do 
something like


to http://blabla.edu/services; whereas with REST, we just do an HTTP PUT 
of the XML structure <ingredients> to 

The distinction is that REST provides a clear separation between 
something that is addressable as a resource - the ingredients of the 
recipe - and operations that can be carried on it - updating - whilst 
SOAP conflates the two in messaging (and requires extra machinery to 
make it work).

Now the reason why 
"http://blabla.edu?service=cutout&POS=301,22&recipe=bombayduck" is not 
RESTful is not to do with its idempotency but that it is RPC-like. 
Semantically it's actually doing the same conflation of resource and 
operation that the SOAP message is doing: one can envisage 



More information about the grid mailing list