Google just announced that they are getting ready to kill 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. We briefly talked about that in abstract terms a couple of years ago but  here are 3 simple reasons why:

Reason #1
JSON is a lot simpler than XML+XML Schema and is more isomorphic with the relational data stores most services use for persistence.

Reason #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.

Reason #3
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.

And the gap will continue to widen as the open web stack matures and things like Open ID and OAuth become more widely spread.

If you are looking for a best practice implementation, take a look at the Friendfeed API.

Note: I can see my old friends saying: “But Edwin, JSON+REST is just a binding component, we already have support for that” :-)

Author: @feedly

Read more. Know more.

13 thoughts on “JSON+REST vs. XML+SOAP”

  1. In this particular case, Google is probably moving to JSON mostly because they actively use these web services in an AJAX context. JSON being specifically designed to be dealt with by JavaScript, it makes a lot of sense.
    In other applications (based on server-level language), it makes sense to use SOAP as it is supported by most languages by default.

  2. Yves. Although JSON works indeed very well in Javascript application, it works equally well on the server side (our back-end is entirely implemented in Java using MySQL and Memcached through hibernate). JSON is just a very simple and efficient way of representing data structure. Based on my experience 5-10% of applications really need the complexity/composition complexity of XML+XML schema. Of the rest, I think that JSON gives you the same value with a lot less complexity and more efficiency.

  3. Why can’t SOAP just leave XML alone and use JSON… JSON is still just a serialization/de-serialization format. REST is very limited in it’s semantics. I am not necessarily saying that SOAP is where it should be. But REST is so bound to HTTP, we can’t even evolve out of it if we are so tightly tied to a lower level protocol.

  4. What worries me is that JSON is somewhat a simplistic data format that has inherently impedance mismatch with XML… making it difficult to interoperate with other services

  5. Unfortunately several of my co-workers are experimenting with REST while I am trying to build a SOA middleware. REST is NOT a middleware technology but as you say is much easier to build since it does not rely on WSDL or XSD. It is not easily integrated into a BPEL project unless you build the REST service using a WSDL (which is possible, but not with the JSON tooling). Otherwise you are passing up all the WS* capabilities and using the service bus. A bit like trying to use a screwdriver when you need a swiss army knife. To be sure I won’t be able to re-use their work in any of my projects. Yes, new technology is fun, but dont use it for everything just because it is easy to create unless you want to brag to your friends about how you were able to use a screwdriver to clean a fish.

Comments are closed.