Skip to Content


My attention to the discussion concerning SOAP was attracted by a personal talk at the SAP Weblogger Meeting in Walldorf on Juli, 15th. There, DJ Adams stated his sense of understanding about SOAP, which he formerly expressed in his article Real Web Services with REST and ICF and supported thru his weblog Forget SOAP – build real web services with the ICF.

After reading/scanning these resources published by DJ, I hope to have understood him correctly. Fulfilling this precondition let me clarify things and tell you my opinion on SOAP vs. HTTP/REST. Please note that I have not read Fielding’s dissertation completely.

Definition of “Web Service”

There seems to be a different understanding between DJ and me what a Web Service is. This is OK as definitions are not laws. Here’s the significant part of a definition from Webopedia, which satisfies me:

“Unlike traditional client/server models, such as a Web server/Web page system, Web services do not provide the user with a GUI. Web services instead share business logic, data and processes through a programmatic interface across a network. The applications interface, not the users. Developers can then add the Web service to a GUI (such as a Web page or an executable program) to offer specific functionality to users.”

Architectural overview and comparison

We go on by visualizing the two paradigms in question. After that follows the comparison of both concepts.

Architecture of HTTP-based Web Services

My picture of a Web Service architecture based on HTTP as DJ described it in his article and blog is the following, if I understood correctly:
The yellow area surrounding the three URL’s indicates that all three URL’s should belong to the same internet domain. The box reading “Parameters” should have been attached to the “URL” box as parameters are encoded within it. But to outline the fact that parameters are attached to services the current positioning seemed more approriate to me.

Architecture of SOAP-based Web Services

Here the schema of a SOAP-based architecture for Web Services:
In contrast to the HTTP approach there is only one central URL. It is representing the server address serving SOAP requests. The WSDL displayed above is the Web Service Description Language, containing services available (i.e. methods), parameters applicable to that services and metadata. The WSDL file is sent to the central URL


As the next picture shows one can match several elements of these two concepts.
So there really is not that big a difference between them! It has to be remarked that metadata is not part of the HTTP-concept. Now consider the following.


Authentication issues

As DJ writes in the paragraph “SOAP and Firewalls”, a firewall admin should determine the accessability of several Web Services. He writes “With HTTP, the firewall administrator’s job is easier. What’s the verb? POST? Ok. What’s the noun? /some/path/to/a/data/element. Ok, not allowed. Job done.”

Well, I talked to a collegue (technical oriented) and a network administrator doing firewall stuff as well. For us three it does not make any sense to authenticate the access to a bunch of Web Services with help of the firewall. Perhaps I am missing the point, but how should the firewall admin know, what happens when someone calls a specific Web Service? Example: Let there be a Web Service called giveMeDJsMailAddress. Who can tell me what this particular service does? NO ONE CAN! The only person being in the position to do so quite probably is the developer implementing the functionality behind that Web Service. Who says that giveMeDJsMailAddress is not doing something the firewall admin does not know and if he did would not allow it. But just given the name of a Web Service (or the verb and noun, like DJ wrote) is not enough to really know what’s going on. And as there is no metadata available for DJ’s HTTP approach, things get even worse.

BTW I am of the opinion that a firewall admin should let his hands from doing authentication on functional level. He/she should only decide which ports to release and which URL’s to block in general (e.g. forbid employees to access eBay from within the company during work).

DJ: Have I mixed something up here? I cannot imagine you meant it the way I observed it.

And to use a metapher as an argument: Wouldn’t you wonder about a company securing a shop floor by using a fire door as authentication mechanism? Fire door and fire wall are not that different!


DJ’s HTTP-based suggestion for Web Service handling does not include metadata at all. This is at least my impression from the readings I did and from a personal discussion with him. In my eyes, metadata is essential to Web Services. Metadata is gaining a very high importance in the future. Just look at the Semantic Web, UDDI or annotations in Java. Without metadata there is no information. Metadata is the vehicle to add semantics to data to convert it into information.

Parameter Delivery

When calling a Web Service there are often parameters attached to it. It seems to me, that in DJ’s concept, they are delivered thru the URL also used for calling the Web Service itself. Several things come to my mind when thinking about it:
There are more elegant ways to attach parameters to a function call than thru plain text within a long URL. And separation of concerns is a paradigm that angles off. Perhaps this is too theoretical, but the separation of data and specifications should be not bad at all.


While the previous paragraph is not that important in general, the authentication issue for itself should be enough thinking over HTTP-based Web Services. I hopefully managed to clarify the differences and similarities of both concepts, SOAP and HTTP, while not explaining all details.

IMHO, DJ’s statements have its eligilibity and it is good to have someone thinking about aspects being seen for granted by many people. Thank you for that, DJ! The REST principle is something we should keep in mind whenever possible. But as the situation displays to me after reading DJ’s article and weblog, I cannot identify the advantage of his HTTP concept over SOAP on a broad basis. P.S.: Please allow me to answer earliest on the 24th as I am on vacation until then 🙂 Because of this constraint and because of wanting to post this blog immediately I also could not synchronize it with the editorial staff.

You must be Logged on to comment or reply to a post.
  • There are many ways to have metadata in a REST based protocol. One of which being WebDAV properties (RFC2518), which, as a matter of fact, already works in Netweaver’s KM.

    Parameters do not need to be part of the URL. They can (and in some cases should) be part of the HTTP message. For instance, you can have parameters inside a POST request body both in SOAP and in a REST based system.

    SOAP hides semantics inside the POST request body. REST tries to expose semantics in well-defined HTTP methods (if it’s GET, it doesn’t have side effects, DELETE does what it says, and so on…).  If the method vocabulary of RFC2616 (HTTP/1.1) does not suffice, just add new methods like WebDAV (RFC2518) already does. HTTP intermediates/proxies/firewalls should be happy to find out about method sematics by just looking at the method name, instead of having to parse SOAP request bodies.

    Best regards, Julian

  • Web Services and GUIs – REST design allows for GUI free service interaction – this is essentially what HTTP based Content-Type negotiation is all about.  Infact it is an extremely efficient design in the respect that the media type can be negotiated for a GUI based interaction, or an automated/robotic one.

  • Hi Klaus

    I’m glad I got the chance to meet you last week.

    Now I’m back from the weekend, I thought I’d write a few comments in
    reply. (I notice that Piers and Julian have already contributed, so I
    will try not to repeat things that were already covered).

    It’s worth pointing out now the point I laboured in the SDN
    meetup last week – that healthy debate is good for the mind, and
    should be encouraged; so any disagreements are just that –
    disagreements 🙂

    First, I don’t disagree with the Webopedia’s definition of a web
    service (at least the part you quoted); it’s rather generic and loose,
    which is exactly the point. To labour this further – some people
    say that the involvement of XML is fundamental to web services.
    I don’t agree. It’s not even as tight as that. Why does something have
    to be encoded in XML to be a web service? That’s ludicrous. That’s what
    MIME is for – medata at the HTTP header level to describe the data type
    and encoding.

    Regarding authentication issues – it seems odd that you say that the HTTP
    approach has no metadata. If there’s one (of the two) that’s lacking
    metadata, it surely is SOAP. In one approach, the intent of the
    incoming request is clearly defined in the HTTP verb. In the other,
    the intent is not available, because a single verb is used in each
    case. Likewise, in one approach, the data target of the incoming
    request is clearly identified and addressed – via the URL. In the
    other, a single central opaque URL that does not relate to the data
    being addressed in the web service call. Finally, in the exchange of
    request and response, in one approach headers are used for the exchange
    of metadata (such as content type). In the other approach they’re less
    relevant (although arguably available) as the request is hidden inside
    an XML envelope in the HTTP body.

    Guess which approach is which? 🙂

    I know firewall admins too, and can say that in some cases at least,
    they don’t even consider (what I regard as) doing their job properly
    because of the way SOAP tunnels through well-known ports – the task is

    Regarding metadata – I’m not sure why you think that the REST approach
    precludes metadata. There’s no argument in REST that says you can’t
    have descriptions or catalogues of web services. If you’re referring
    to the XML in the payload, there’s no argument in REST that says you
    can’t or shouldn’t use XML as the format of the state.

    Regarding parameter delivery – I think a lot of the thinking here is
    related to the fact that SOAP is an RPC mechanism (or at least, the
    SOAP deployed today). But the model of REST and HTTP (used properly)
    is a different one to RPC. It is all about representing data objects
    as first class web citizens, and interacting with those objects (via
    HTTP verbs). In those interactions, the ‘parameters’ are, on the one
    hand, in how those objects are addressed (i.e. the URLs used), and on
    the other hand, ‘sent’ along with the HTTP body representing the state
    being manipulated.

    It’s worth pointing out that REST doesn’t relate to SOAP as, say,
    XML-RPC related to SOAP. XML-RPC and SOAP are (for a large part)
    similar things. They are RPC mechanisms encoded in XML and transported
    using a subset of HTTP. Behind REST is the idea that the web isn’t
    built on a load of RPC services, it’s built on something different.
    It’s built on an application protocol that brings addressing and
    manipulation of resources (data objects, for want of a better phrase)
    to the fore.

    As a final part to this reply, let me point you to the REST wiki,
    which can provide more information (and give pointers) on REST in a
    much better way than I can. It’s at:

    Kind regards

    • Hi DJ,

      wow, that’s sort of an answer I like! Thanx DJ.
      With my reply I won’t go into details. What follows is my general point of view about the matter.

      I read the important parts of the Wiki you provided the URL for. The discussion on How SOAP Compares to REST ( shows me that there is not one obviously correct (or the one and only legitimate) point of view. I must admit that after reading the Wiki the advantage of REST over SOAP does not come that clear to my mind. Although it pointed out – as your answer and the other two answers to my blog did – some differences between the two paradigmas.

      One point not only mentioned in the above Wiki but also stated by yourself at the SDN meeting in Walldorf is the distinction between a transport and an application protocol. OK. It seems to me that SOAP is seen to abusing HTTP a little and that with HTTP you could do anything as with the more complicated S[imple]OAP. But it should be OK to add a layer to an already capable mechanism because of several reasons. This is as it was with assembly language and higher-order languages. I don’t want to argue by comparing these different fields of technologiy, but just want to indicate with this that it could be senseful to add a more convenient layer (perhaps the attribute “convenient” is not accepted by everyone).

      If I could see a (slightly complex) real-world example showing both REST and SOAP at work and pointing out the advantages of SOAP to me clearly, I would change my opinion. Perhaps you, DJ, Piers, Julian, or someone else could post a blog to visualize some important aspects of REST versus SOAP.

      Kind regards,