fyi REST vs. SOAP: Which SOA Is More Popular?

All:

Pointer to article:
http://billburnham.blogs.com/burnhamsbeat/2004/12/rest_vs_soap_wh.html

Kobielus kommentary:
This blog item would have been more useful if the author had gotten some basic points straight.

Most significantly, he fuzzes the distinction between SOA and REST. Both are architectural styles for designing distributed Web services, but they differ fundamentally in how they enable ubiquitous interoperability.

Under SOA, endpoints expose their interface semantics as service contracts, and may define any arbitrary interface semantics they wish, so long as they are described in platform-independent syntaxes such as XML Schema, WSDL, and WS-Policy. Under REST, endpoints rely exclusively on HTTP’s limited interface semantics for creating, retrieving, updating, deleting, and obtaining metadata on resources (i.e., PUT, GET, POST, DELETE, HEAD). REST doesn’t support arbitrary or application-specific protocol interface semantics. So—contrary to the post’s headline—REST is not an SOA. Nor is SOAP, for that matter: it’s a middleware protocol that is often used in SOA-based environments (along with XML, WSDL, UDDI, etc.) for any-to-any interoperability (RPC-based or document-based).

Essentially, REST refers to the WWW—which is of course ubiquitous—but with some additional architectural constraints (it’s hard, from reading this article, to know if all the constraints are satisfied in the Amazon example). In addition to the rigid reliance on HTTP’s protocol semantics, REST doesn’t support stateful conversations among agents and resources. Under REST, all state information must be contained in the self-describing messages interchanged beween agents and resources. Other REST features include a separation of presentation from business-logic and data tiers, caching of resource representation data in intermediary caches, and on-demand code provisioning.

I don’t take issue with his basic point that REST—as a Web services architectural style facilitated by the ubiquity of the WWW—is more common than SOA. REST is a simpler interoperability style that makes do with the basic ingredients of the WWW: URI/URL, HTTP, HTML, and DNS (not a shred of XML in that basic equation). Therefore, REST is the common denominator interoperability path of least resistance.

But REST is not necessarily a competitor for the richer, more flexible, more robust world of SOA (based on XML, SOAP, WSDL, UDDI, and so forth). Like the WWW, REST is more purely a style for presentation-tier interoperability. For complex integration within and between all the tiers (presentation, business-logic, and data) of your distributed environment, SOA remains the most appropriate style.

Jim