UWS as a REST protocol
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:
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 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
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