Home > Programming / tutorials > Goodbye SOAP – Welcome JSON REST

Goodbye SOAP – Welcome JSON REST

November 2nd, 2010 Leave a comment Go to comments

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


Simplicity vs Utility . Why SOAP Lost

Categories: Programming / tutorials Tags: , ,
  1. November 28th, 2010 at 21:16 | #1

    @Vinay I wasn’t suggesting serializing everything into JSON (doable? maybe), but the HTTP response generated for any RESTful HTTP request may return data in any format (application/json or application/rdf+xml or text/xml or image/jpeg). My point is – RESTful web service need not to tie with only JSON, and a data interchange format shouldn’t be used to compare with web service architecture like SOAP (comparing an apple with a car?)


    It is really up to the service provider to decide what format HTTP responses should be delivered (iirc, one may also request/suggest response to be returned in specific file-type by specifying the ‘Accept’ header while doing HTTP request), all they need to do is just change the ‘Content-type’ HTTP header (sadly most ppl don’t do this correctly). Therefore, besides JSON, XML (you will never know when you will need structured data, useful for RDF/XML serialization as well, not forgetting RSS/ATOM feeds) or even binary data like images can be used as response, eg. flickr can return XML (please check the link above) as well as JSON.

    Using REST is just really using HTTP in the proper way (or in the way it is designed) to do CRUD over the network, there is no standard around to guide a developer on how to develop a RESTful service. Therefore, on top of REST, you have to implement your own authentication and authorization system (usually via oAuth/OpenLogin these days), input data validation etc (so this doesn’t make REST so sexy anymore huh?). However, I have not find the time to read through the doctoral dissertation and may have mis-interpreted, as I first found out about rest here – http://tomayko.com/writings/rest-to-my-wife

    I know even less about SOAP/XML-RPC so can’t really compare them with REST (probably should go read the dissertation before read up on SOAP and XML-PRC). Please do correct me if I’m wrong.

  2. November 26th, 2010 at 11:13 | #2

    If you want to transfer xml data , go for SOAP. As far as I know, you cannot do file transfer in JSON .

  3. November 25th, 2010 at 19:36 | #3

    JSON do not necessary has to be the only data interchange format for RESTful implementation, no? For those who require to transfer a lot more info (like RDF/XML), they can still use REST right? I am really new with REST, please correct me if I’m wrong

  4. Mathew Thomas
    November 25th, 2010 at 12:26 | #4

    I agree completely. SOAP and JSON both have their strengths and weakness. Folks turning away from SOAP because of strong typing complaints are just not getting it. You have choices – use what is appropriate w/o disparaging the other.

  5. hisaak
    November 25th, 2010 at 03:55 | #5

    Finally somebody with eyes opened.

  6. Dusty
    November 24th, 2010 at 17:06 | #6

    I think the problem is that the author suggests that you have to choose one or the other.

    1) ‘isomorphic’ argument. This contradicts itself, first saying it’s simpler (which is true), then suggesting that it can better support complex data (which is not).

    2) Absolutely true… JSON (not REST) has a much better support in browsers. On the other hand, there is absolutely no support for REST in browsers at-large.

    3) Caching – no difference, caching is the same for both… in fact, because of XML’s overhead, caching is more of a bonus for SOAP.

    4) If you’re writing your own SOAP *OR* REST interfaces, you’re doing it wrong. They should be generated for you. This also contradicts #1, as it suggests modeling your JSON data, whereas #1 says that JSON is isomorphic when compared to the data in your DB.

    5) Makes no sense, also, the url you use wouldn’t be cached by most browsers (see #3)… in fact, a proper REST url would look like: http://guru.com/score/007

    I’m not sure you really understand REST….

    That said, REST is a great technology when implemented by people that understand what is going on. Unfortunately, there are a LOT of people who decide to use REST because it’s the quickest way to go live with their site… You should use REST only after you’ve determined what your API should be. Otherwise, ever single change in your code will cause huge regressions throughout your application that are impossible to catch, because you’re using fully un-typed data-transfer.

  7. Prasad
    November 24th, 2010 at 14:41 | #7

    I think the article is not Smoke and Mirrors. I would use SOAP for typed messages… have used JSON for messages and am pretty impressed by it as well. Nice article to highlight some features.

  8. November 24th, 2010 at 13:43 | #8

    I’m working for a large railway corporation and we just decided today to use JSON-RPC 2.0 (rather than SOAP) for our new booking system interface, for the sake of performance of course. However I agree that JSON lacks a commonly accepted description meta-language and this makes the contract first approach hard for cross organnization interfacing. Sure there is JSONSchema, but there is virtually no tool support for it. I hope to see JSONSchema2Java tools soon!

  9. Remy
    November 24th, 2010 at 12:07 | #9

    Actually, a more resorce oriented representation would be:


    Your example majes it more of a rpc call mascarading as rest.

    However, I mostly agree with the views expressed.

  10. November 24th, 2010 at 11:31 | #10

    This article gives examples of JSON usage and I put my point as to why it is better. Not sure what is so bad about this article Doug.

  11. November 24th, 2010 at 11:28 | #11

    Yes Zhong , it may be too early to say JSON will replace XML every where especially in large corporations but the change is happening.
    We are not talking about JSON replacing XML configurations. We are talking about light weight data interchange.
    And talking about xml replacement in Spring files, we are seeing that happening through annotations.

  12. November 24th, 2010 at 11:14 | #12

    JSON has no chance to replace XML in large corporations anytime soon. XML is everywhere, it is in from hardware appliance to software configuration files. It is not just within an enterprise, it is also heavily used in system integration between major corporations. Can you get the Spring people to replace XML with JSON in their config files?

  13. Doug
    November 24th, 2010 at 11:09 | #13

    This article proves that in software development “if the only tool you have is a hammer, everything looks like a nail”. Or would I say this is another software development horseshit article!

  14. November 5th, 2010 at 10:40 | #14

    Hildebreto, we have unit tests and stubs with which we can test the contents and validate the contract. Good point . I will post on this next.

  15. November 5th, 2010 at 05:50 | #15

    “The deeper problem with SOAP is strong typing”

    Interesting : for me this is actually SOAP strong point !

    With REST, the documentation is often limited to “here is a sample REST message”. ok… but what elements are mandatory ? what are the data types ?.

  16. November 5th, 2010 at 02:06 | #16

    I guess if someone comes up with a test or validation technique for JSON contents, it would soon replace XML in large corporations.

  17. November 4th, 2010 at 10:17 | #17

    Shypo, What I am reading and from Google switch to JSON, I guess even big
    fish are realizing that JSON+REST is way to go.
    There might be some enterprise client still hooked on the legacy of SOAP.

  18. November 4th, 2010 at 07:10 | #18

    XML is heavier than JSON! As you mentioned “big fishes” are using this solution.

  1. November 4th, 2010 at 12:46 | #1
  2. December 25th, 2010 at 18:16 | #2
  3. December 28th, 2010 at 22:39 | #3
  4. January 27th, 2011 at 14:10 | #4
  5. April 21st, 2012 at 16:29 | #5