November 20, 2002

Web Services are more than just SOAP

Mark Baker made the following comment in his weblog post about Uniform Interface, take 12

Being able to retrieve anything is a big win. Processing it is indeed an issue, and a non-trivial one (as I just alluded to), but with Web services, you've got both the problem of being able to get the data and the problem of knowing how to process it. The Web solves the first problem, and that's just with the GET method!

It seems to me the big thing that is missing in a REST architecture is a standardized way of describing the payload of a HTTP reply in some machine readable format, and a way of linking the URI of the request with that definition. Even Tim Berners-Lee and Dan Connolly at W3C seem to hint at this need when they discuss vocabularies in their paper "Web Architecture: Extensible Languages".

If we ignore for the moment the SOAP encoding data model part of the spec, then SOAP is roughly equivalent to the HTTP request/response. The thing that Web Services technology does get right is having a description of the message payload format available through the WSDL definitions of that Web Service interface.

This allows the syntax of the payload data to be deduced automatically, and or course the semantics of this payload are then handled by the application itself.

This is one of the main reasons why for me the term Web Services always equates to WSDL + SOAP rather than just SOAP on it's own. Without the WSDL, you have to deduce the payload format through ESP or some out-of-band private agreement between the two parties.

Of course, this does mean there is an application-specific schema rather than a generic one, but that is what makes Web Services an application access technology rather than just a resource access technology!

Entry categories: Web Services
Posted by Jorgen Thelin at November 20, 2002 12:45 PM - [PermaLink]
 
Traceback List
Comments
What Tim and Dan mean by "vocabulary" is purely local to a representation, and doesn't impact HTTP (at least to a first order approximation - optimizations may required exposing them as HTTP representation metadata). They basically mean that a document can be compound, or in 2002-speak, a document comprised of multiple XML namespaces. The partial understanding issue is how to process the document without knowing all the namespaces in it. FWIW, this note of theirs helped frame the requirements for XML Namespaces. I don't *think* it has much to do with the point of this blog. REST is *extremely* late-bound as the methods are pre-specified. But you can't/don't know, a priori, what data format you might get back, or what data format is accepted through that interface, which is why the protocol itself has features like the 406/415 response codes, and content negotiation, to help manage all that extended-interface stuff at runtime. Posted by: Mark Baker on November 21, 2002 07:46 PM