Goodbye SOAP – Welcome JSON REST


News: Goodbye SOAP – Welcome JSON REST

  1. Goodbye SOAP – Welcome JSON REST (4 messages)

    Representational State Transfer (REST) is a software architectural style for distributed hypermedia systems like the world wide web.

    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.

    Let us look at  Why REST + JSON is a good choice over SOAP?


  2. Bananas are better than oranges[ Go to top ]

    Apparently bananas contain more Vitamin C than oranges. Let's get rid of oranges ...

    Why do we always need to be so exclusive. I love Json and use it excessive. But if I require a typed message between two (separately managed) systems I will always go back to SOAP.

    Both are very good message formats having very good uses!

  3. SOAP vs REST wars make no sense[ Go to top ]

    These are just different technologies, good at different things.

    REST advocates keeps on saying it is easier to use, which is right, and good... for limited usage. If transactions are a requirements, then REST has almost no solutions to offer (how do you offer atomicity over several REST requests, on different services?)

    SOAP is more complex, but lets one define strictly the data format (yes, data model, versioning and data transformation ARE important in enterprise SOA, there are lot's of cases where you just may not change the data format without notice, existing clients needs to be adapted, and strong type gives you good control on that), gives you transactionality and fine grained security, 


    Let's just use whatever is best in each situation, without religious position pro or against REST and or SOAP.



  4. I think that's basically it, if you're doing transactional work where money is changing hands, SOAP's fragility is actually something of a plus.  One wants to be a little paranoid and quick to fail if things aren't exactly in alignment.


    On the other hand, REST is the way to go when the task at hand is accessing data or straightforward CRUD type requests and you want something that will be easy to support once in production, and can scale easily.  


    I'd tend to say, go with REST as the default approach, falling back to SOAP if the need for maintaining transaction state is high, and/or the general level of paranoia needed is high.

  5. While both REST and JSON are neat, and can (and do) certainly replace most SOAP use cases when combined, a few points got lost in the author's enthusiasm:

    • SOAP can transport JSON as well as REST can. It's unusual, but certainly possible.
    • SOAP has WS-Security, which is superior to HTTP-based mechanisms like HTTPS and basic/digest authentication.
    • SOAP is transport-independent. While HTTP is far and away the most popular, others (like SMTP, messaging and raw sockets) are available and are being used.
    • Strong typing can get in the way, but it also has undeniable advantages. To call that "the deeper problem" in disingenuous.

    Yes, the whole WS-* system was a step too far in the wrong direction. But SOAP is here, it works, it's no longer hard to deploy (even if it's no good from within a browser), and it does have some advantages over REST, as well as some disadvantages. It remains a viable architectural tool.