Goodbye SOAP – Welcome JSON REST
We look at the leader to give us the guidance.
Not sure if that is quote or not but when Google , Apple , facebook or some of the best companies take some step, it is time to take notice.
Google has killed their SOAP API. XML+SOAP was a good milestone in the history of integration but it is now time to look at the next milestone and that next milestone is JSON+REST
What is REST ?
Representational State Transfer (REST) is a software architectural style for distributed hypermedia systems like the world wide web.
The term originated in a 2000 doctoral dissertation Architectural Styles and the Design of Network- based Software Architectures about the web written by Roy Fielding, one of the principal authors of the HTTP protocol specification, and has quickly passed into widespread use in the networking community.
What is SOAP ?
Simple Object Access Protocol . SOAP is an XML-based messaging protocol. It defines a set of rules for structuring messages that can be used for simple one-way messaging but is particularly useful for performing RPC-style (Remote Procedure Call) request-response dialogues. It is not tied to any particular transport protocol though HTTP is popular
Why REST + JSON is a good choice over SOAP?
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
In a REST based architecture everything is a resource. A resource is accessed via a common interface based on the HTTP standard methods. Every resource should support the HTTP common operations. Resources are identified by global ID’s (which are typically URIs).
If you want to know about the history of REST, go through this
Other posts worth reading on REST