XML+SOAP was a good milestone in the history of integration but it is now time to look at the next milestone which is JSON+REST.

What is Rest?
REST stands for Representational State Transfer. (It is sometimes spelled “ReST”.) It relies on a stateless, client-server, cacheable communications protocol — and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

What is JSON?
JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition – December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

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.

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).