Enterprise Geeks Podcast – SOAP vs. REST

Should SAP give SOAP a REST?

Should SAP give SOAP a REST?

In this great episode, come get some schooling as Ed hosts a discussion between the two heavyweights, Thomas Jung and Dan McWeeney on SOAP vs. REST in the enterprise and the possibilities for both in the future.

If you have questions, suggestions, or topic ideas for future episodes, give us a shout here. Enjoy!

Running Time: 41 minutes

Talking Points

  1. 00:15 – Thomas is on the move
  2. 03:00 – SOAP vs. REST
    • What’s the debate? – Thomas
    • SOAP explained for the REST of us – dan
    • When would you use one vs. the other in the enterprise?
    • What is SAP doing to adopt REST
    • Can services revolutionize the way we look at enterprise data?
  3. 30:45 – Wrap-up cars, games, and corn fields

10 responses to “Enterprise Geeks Podcast – SOAP vs. REST”

  1. DJ Adams says :

    Thanks for bringing up this topic in the Enterprise/SAP world. While I’d disagree on one of the ideas expressed (that SOAP is more appropriate for more complex enterprise scenarios) I think you aired an even handed and very useful discussion, with good background information for those enterprise architects that need to understand the balance.

    I’d like to emphasis more differences, which are fundamentally philosophical but practically important:

    SOAP: object approach
    REST: document approach

    SOAP: predominant non-uniform ‘RFC’ style
    REST: uniform interface

    SOAP: opaque data
    REST: transparent data and addressability

    SOAP: heavy, expensive/harder to maintain / debug
    REST: light, cheaper/easier to maintain / debug

    Ad nauseam 🙂

    Thanks again for raising this in the SAP world

  2. Sergio Ferrari says :

    Great pod !!! thank you very much.

    I would add that
    REST: allows better computer utilization
    SOAP: allows automatic code generation starting from wsdl

    Like you said, the typical REST communication begin with the first XML that contains the links to the others (ProductList and links to ProductDetail). The subsequent queries to get each ProductDetail can now be executed in parallel (asynchronous) that also mean each query can be dispatched by different instances of the web server. That, as google does, perfectly distribute the wokload on different web servers even located into different datacenter.
    Indeed the SOAP approach normally has to return all the data within the first XML putting the workload on just one server that to balance the load can allocate to an application server the complete request.

    Even if already told by you, I would repeat:
    SOAP: asynchronous (WS-RM)
    REST: synchronous only
    that means REST can be compared to SOAP speaking about MVC integration (View -> Model via SOAP or REST) but not when speaking about asynchronous and reliable A2A integration

  3. DJ Adams says :

    Hi Sergio

    I’d have to disagree with your statement that REST is synchronous only. There are many instances when a REST-based application model can describe asynchronous integration. HTTP callbacks, or Webhooks, describe an asynchronous model. An example of a non-callback approach might be: POST an entity representing a long task to a container resource. The response is a ‘job accepted’, with a newly created resource (URL, location) that the submitter can query for status.

    You also have to be careful when suggesting that REST is not appropriate for reliable A2A communication. It certainly can be.


  4. KK Ramamoorthy says :

    Great podcast and I like the idea of a future framework that is a blend of SOAP and REST. What I don’t understand is how is REST non-static regarding data definitions, as highlighted by Dan. Any application program needs to have some sort of data definition to derive meaningful information from the data. Even with dynamic programming, we still have to anticipate data in a certain format. In case of REST, I agree that the data definitions are not needed (like WSDL) during design time but the code that is going to parse the XML response, for example, still assumes some sort of parent/child relationship in the data.
    Regarding other comments on SOAP is preferred for asynchronous integration, I would say it makes more sense when there are more than two parties involved in the integration, where data is persisted in different systems and encryption of the actual message payload is just as important as the transport level encryption. Yes, REST can be improved to support many of these requirements as well but then it wouldn’t be light weight as we know of.

  5. DJ Adams says :

    Hi KK

    While there are certainly plenty of instances where XML will be used as the serialisation format for data exchanged in a REST style, it’s important to bear in mind that REST does not necessarily imply XML as a payload. REST’s main (and only major) instantiation in the real world is HTTP, and of course there are plenty of MIME-types to describe different types of data. Like I mentioned in an old conversation on SDN (https://www.sdn.sap.com/irj/scn/weblogs?blog=/cs/user/view/cs_msg/1011), you wouldn’t encode a binary format such as an image and then stuff it into XML just to send or receive it, would you? And of course, there’s always plain text. Who says that the best way to transport data is “in the bucketload”?

    On data format, consider JSON, which is (a) an alternative to XML (although that’s not why I’m bringing it up here) and (b) format-free. But (dynamic) applications happily have their integration powered by data in that serialisation format without format worries. XML Schema? Do. Not. Want.

    I’m not sure what you mean when you say SOAP makes more sense for integration with more than 2 parties. For one thing, encryption != integration, and for another thing, look to the pipeline programming model. N parties are involved, and nobody breaks out in a sweat.


  6. KK Ramamoorthy says :

    @DJ, thanks for your comment. Regarding more than 2 parties, I meant integration scenarios that are serial in nature where the message makes multiple hops. If the message is persisted all the way through and if you want to maintain single sign on, SOAP has options like SAML, not sure if REST APIs have options?

  7. Murray Spork says :

    I would like to elaborate on DJ’s comment about mime types: One of the many misunderstandings about REST is that it implies “contract free”. In reality, the combination of HTTP and HTML gives a very explicit contract – actually a much richer contract than any WSDL could ever give.

    The confusion comes because people think of HTTP as a transport protocol – when in fact it is an application level protocol. By itself, HTTP is not sufficient; as DJ already implied – you also need an associated “media type” (such as text/html).

    The challenge for those who want to use HTTP for server-to-server communication in a true RESTful manner, is that you need to find the appropriate media-type to play the same role that HTML does for browser-to-server communication. Protocols like Atom and Atompub get you some of the way. But even a combination of HTTP + Atom + Atompub is not sufficient. Of course, most of us don’t want to have to define our own media type for every single application we want to expose this way. The way Google handle this with their GData APIs may be a reasonable compromise (is not strictly RESTful – but it’s probably close enough to still capture most of the benefits of REST).

    BTW – Dan’s explanation of the extreme late binding nature of RESTful services was great. Fielding called this “Hypertext as the engine of application state”. This can be a difficult thing for developers, who are more used to RPC style integration, to get their heads around. If you find people describing their Web APIs as “REST based” – but you find no (or very few) URLs are returned in any response body – then please dismiss the “REST” label in this case as pure marketing.

  8. Thomas says :

    Thanks for the podcast was fun listening to it. Here are my 2 cents concerning REST vs. SOAP based on my experience working with REST in my current project.

    1) SOAP is pretty slow compared to REST. So if you want to build a client server application and need really fast response times I would recommend REST since the SOAP stack is quite heavy.

    2) For me the biggest thing about REST vs. SOAP is how it changes my thinking about the architecture of the application. I like to call it Verbs (SOAP) vs. Nouns (REST). In REST the set of verbs are fixed. If you decide to use REST via http you are limited to GET, POST, PUT and DELETE. Every resource which you expose via REST only has those set of verbs. SOAP on the other side offers the flexibility to bundle a couple of verbs. Let me give an example. Consider a scenario in which a user has to log into an application.

    A possible REST solution would have one resource called session. You can then map the http verbs to the resource:

    – GET /session -> Return whether the user is logged in or not
    – POST /session -> Creates a new session for a given user
    – DELETE /session -> Logs out the user
    – PUT /session -> Update the session with some new information

    A possible SOAP solution could be a bundle of services:

    – LogInUser()
    – LogOutUser()
    – IsUserLoggedIn()
    – UpdateUserInformation

    It is quite interesting how your perception of a domain changes once you move from verbs to nouns.

  9. DJ Adams says :

    (Great comments, Murray, by the way)

    Thomas, also great comments, but I’d like to address the ‘limited to GET, POST…’ angle. You pretty much nailed it when you described how it changes your thinking about the architecture. So in that way, don’t see the HTTP verbs as being limited, see the interface as being uniform, consistent, and predictable. You can have as many nouns — resources, URLs, *things* — as you desire, and the way you manipulate those things is the same no matter what. This approach gives many advantages, not least in being able to properly use application firewalls to see what the intent of an incoming call is.

    Contrast this with SOAP, where there is no consistency, no uniformity. With REST you get the verb, and the intention, in the header; you don’t need to look into the body. And that verb predictable. With SOAP, you not only have to look into the body to find the method name, but also have to figure out what it’s going to do (Only read? Update? Create? etc). The inconsistency can even be seen in your example list of SOAP calls (I know it’s only an example, but nonetheless…).

    Anyway, I totally agree with the fact that your perception changes.


  10. Raúl Mosquera says :

    Cool podcast, very interesting and funny n_n.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: