JSON+REST vs. XML+SOAP

http://blog.sina.com.cn/s/blog_4ba0876e0101393g.html

For some "out-men" like me

Google just announced that theyare getting ready to kill their SOAP API. XML+SOAP was a goodmilestone in the history of integration but it is now time to lookat the next milestone and that next milestone isJSON+REST. Webriefly talked about that in abstract terms a couple of yearsago but  here are 3 simplereasons why:

Reason #1
JSON is a lot simpler than XML+XML Schema and is more isomorphicwith the relational data stores most services use forpersistence.

Reason #2
Browsers can consume large amount of JSON much more efficientlythan they can consume large amount of XML and the gap is wideningbecause the latest versions of the browsers are now providingnative, safe support for encoding and decoding JSON.

Reason #3
REST interfaces are much easier to design and implement than SOAPinterfaces: verbs are already defined, exception semantics arealready defined, caching semantics are already defined, versioningsemantics are already defined, authentication and access controlare already defined. All you really need to focus on are modelingresources using JSON, modeling URL hierarchies, modeling searchpatterns and modeling batching for performance improvements.

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

If you are looking for a best practice implementation, take a lookat the FriendfeedAPI.

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