The deeper problem with SOAP is strong typing. WSDL accomplishes its magic via XML Schema and strongly typed messages. But strong typing is a bad choice for loosely coupled distributed systems. The moment you need to change anything, the type signature changes and all the clients that were built to your earlier protocol spec break.
The REST / HTTP+POX services typically assume that the clients will be flexible and can make sense of messages, even if they change a bit. And in practice this seems to work pretty well. Twitter , yahoo web services , Flickr ,del.icio.us, technorati, all use use REST.
Some more differences
1. JSON is a lot simpler than XML+XML Schema and is more isomorphic with the relational data stores most services use for persistence.
2. Browsers can consume large amount of JSON much more efficiently than they can consume large amount of XML and the gap is widening because the latest versions of the browsers are now providing native, safe support for encoding and decoding JSON.
3. REST provides improved response times and server loading characteristics due to support for caching.
4. REST interfaces are much easier to design and implement than SOAP interfaces: verbs are already defined, exception semantics are already defined, caching semantics are already defined, versioning semantics are already defined, authentication and access control are already defined. All you really need to focus on are modeling resources using JSON, modeling URL hierarchies, modeling search patterns and modeling batching for performance improvements.
5. Does not require a separate resource discovery mechanism, due to the use of hyperlinks in content. An example of REST service would be http://www.skill-guru.com/getmyscore?userid=007
Whats interesting is though REST has its own advantages so does SOAP.
SOAP is more complex, but lets one define strictly the data format (yes, data model, versioning and data transformation ARE important in enterprise SOA, there are lot's of cases where you just may not change the data format without notice, existing clients needs to be adapted, and strong type gives you good control on that), gives you transactionality and fine grained security,
Let's just use whatever is best in each situation, without religious position pro or against REST and or SOAP.
1 comment:
On one hand SOAP is more complex but it is very well tooled. SOAP tools can auto generate classes for the defined interface easily, in REST you have to write a custom API for each service.
Also SOAP is not immune to API version issues, it is just as easy to mess this up in a hand rolled service.
Post a Comment