JSON+REST vs. XML+SOAP

转载：http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/
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” 

This entry was posted in Architecture. Bookmark the permalink.