[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] ANN: SOAP versus REST
- From: Kurt Cagle <kurt.cagle@gmail.com>
- To: "Costello, Roger L." <costello@mitre.org>
- Date: Sun, 16 May 2010 11:43:05 -0400
Roger,
As per usual, a superb and thought provoking piece.
A couple of comments here, however, as one who has been on the RESTful side of the equation pretty much from the beginning of the debate.
I think its important to understand that SOAP conflates the XML structure with the underlying processing model whereas REST does not. By using SOAP, you are both using a specific transport protocol (which is covered by the WS-* domain) and making use of a specific SOAP envelope to act as the envelope of choice for these processes. It also implies (though doesn't specifically require) that your payload content will be validatable via some form of WSDL, and that in a large number of cases will be used to invoke some form of an RPC (this is general true even when you put message queues and other processing structures at the intermediary points - the destination points are as often as not effectively martialled into binary objects and injected into a binary system). Thus, SOAP based systems tend to fit into an imperative model of development.
The RESTful model is, in a lot of respects, fairly heavily misunderstood, and a lot of what's termed REST technically speaking falls into the broader categories of ad hoc RPCs. The key characteristic of RESTful systems is that they make use of the HTTP protocol for working with resources as if the resources were part of a larger database. Thus, RESTful systems employ CRUD calls - POST, GET, PUT and DELETE respectively - in order to create new records from submitted record prototypes, get a single record or a collection of records that satisfy a given query, put an existing record(s) back into the data store, or delete a record or records from that same data store.
I differentiate between static REST and dynamic REST, but this is hardly a majority opinion. In static rest, the only operation that actually involves processing is POST, which is needed typically in order to assign specific system identification information (and possibly perform validation) upon the incoming resource object (which may be in XML, but may also be in other forms). Static RESTful systems describe the early web, though it quickly devolved into an RPCish mismash, and of course is the core of WebDAV, which was built around this viewpoint.
Dynamic RESTful services are a direct consequence of the marriage of databases (especially XML databases) and web technology. In this model, each HTTP operation has an associated pipeline of actions that are associated with the operation, rather than just POST, and, at least in the models that I see emerging now, recognize that re-rendering on both output (converting a record into an HTML representation, for instance) and input (converting a minimally sufficient XML message into a full message to be inserted back into the database) fall within the domain of such RESTful services. Meta-architectures such as Dan McCreary's XRX are built around this concept, where you have XQuery pipelines serving up RESTful services to XForms clients. As XML databases employ more URL Rewriting, I see these concepts becoming more explicit. Dynamic RESTful services also presupposes that the query is the generalized form of the GET operation on a collection, with the feed being the generalized response, where a feed consists of a metadata header along with a payload of entries, each of which in turn has a metadata header, abstract information, and one or more links to the resource pointed to by the entry (where each link represents a specific representation).
RESTful services are still point to point protocols rather than broader orchestration protocols, but even there I think that the equivalent forms to SOAP architectural structures have evolved with web syndication methods. For the most part, SOAP is push driven while REST is PULL driven. Both are valid and appropriate in the proper contexts (it's hard to imagine a RESTful credit card transaction service, for instance, though its doable) but RESTful services have the advantage that they decouple the update process (POST or PUT) from the query process (GET), which typically will have a much higher demand profile.
Anyway, as I said, just a couple of thoughts.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
