Chris's Rants

Saturday, March 05, 2005

1+1 = 0

Carlos, in his series: Why REST is Better, demonstrates a fundamental lack of understanding of SOAP and REST. Sorry to have to put it so bluntly.

Reading it reminded me of my 9th grade honors algebra teacher's (what is it with all this nostalgia for the 9th grade?) failed attempt at intimidating the class at the start of the school year. He told us that he would prove, using advanced algebra, that 1+1=0 and proceeded to fill the blackboard (remember those?) with all this complex mumbo-jumbo, only to reveal the answer to be... 2. Oops! I never laughed so hard!

In his part 2 of the series he begins:
So let's go over a quick summary of features of REST that we derived in the previous article. These are:

1. Named, optional, default arguments.
2. Coarse grained document passing (i.e. minimize method invocations).
3. Uniform interfaces.
Let's examine these claims with respect to both REST and SOAP.

I have no idea where he came up with #1. I've read Roy's thesis many times. I don't recall ever seeing the word 'argument'. In fact, I just did a search of Roy's thesis and the word 'argument' is, in fact, never used. The term 'named' is used a couple of times, but only in reference to resources: "Any information that can be named can be a resource...", not to arguments.

As for #2, one can just as easily (ab)use HTTP (the closest thing we have to a manifestation of REST) to exchange small messages, with many method invocations, as one can use it to exchange whole documents, er... resource representations, with a very few (one even) method invocations. This claim is not a fundamental feature of REST.

I won't dispute that #3 is a fundamental feature of REST.

Let's now examine these as relates to SOAP.

In the first entry in the series, Carlos wrote:
So let's begin the explanation of why REST is better than SOAP in its support of interoperability. Let's start with a simple method invocation (java syntax):
object.method( arg1, arg2, arg3 );
A collection of these methods is the typical starting point of a SOAP implementation. The first interoperability problem that we encounter here is the order of the arguments. A better solution would be to introduce names, optional, default arguments. In the absence of this construct the way to do this is to objectify all the arguments (see Half-Bean Pattern). So now we have this:
document.arg1 = a;
document.arg3 = c;
document.arg2 = null;
object.method( document );
The advantage is that there is no explicit dependencies in the order of the arguments. Second you have the opportunity to introduce optional arguments. Finally, there is no need to have multiple method signatures for different calling variations. This allows one to design the API to make the most common operations easy to do.
Would someone please point out for me where is it that SOAP constrains one from designing an interface such as this? Sure, the SOAP RPC Representation defines a way of modeling a remote procedure call such that the procedure/method/operation name is the top-level child of the soap:Body, and that the procedure/method/operation's arguments are children of the procedure/method/operation name. However, that is merely a stylized use of SOAP, and an optional one at that. We (the XMLP WG) put this section in Part 2 - Adjuncts for a very good reason. SOAP is not inherently RPC-centric.
SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.
One can use SOAP in exactly the manner in which Carlos is suggesting; to pass a single argument that itself has structure in which the elements are named, may be ordered or unordered, and which can have default values.

Next up, #2 -- coarse-grained message exchange. I've already made it clear that this has nothing to do with REST, nor does it have anything to do with SOAP. It has everything to do with how you use them. You can choose poorly, or wisely, Grasshopper.

Finally, #3 -- uniform interface. Someone please show me where in SOAP it says that you cannot have a uniform interface? I'll wait...

Of course, it isn't fundamental to SOAP that there be a uniform interface, but then again, SOAP doesn't define any verbs. It only defines a message structure (the SOAP envelope infoset), a set of rules for processing SOAP messages, and an extensibility framework. The likes of WS-Transfer and MEST define a uniform interface. Furthermore, as Stefan points out in comments to Carlos' post, there's no reason whatsoever why SOAP cannot be used in a completely RESTfull manner. It is, afterall, just another media type which can be exchanged using HTTP. In fact, David and I were discussing this very topic over dinner last night.

A little Clapton was never more apropos:
It's in the way that you use it,
It comes and it goes.
It's in the way that you use it,
Boy don't you know.

And if you lie you will lose it,
Feelings will show.
So don't you ever abuse it,
Don't let it go.

Nobody's right till somebody's wrong.
I can't wait for the third installment in the series. Carlos promises to cover asynchronicity, whatever that means.

Frankly, I grow weary of this incessant argument that REST is better than SOAP, nyaah, nyaah, nyah, nyaaah, nyaaah. The point is moot, as in:
... people also began to look at the hypothetical side of moot as its essential meaning, and they started to use the word to mean "of no significance or relevance." Thus, a moot point, however debatable, is one that has no practical value.
REST is an architectural style. SOAP is a message format with a well defined processing and extensibility model. Comparing the two is like comparing HTTP with HTML.

I would much prefer that the discussion be focused on how we can leverage the two synergistically. I find that far more interesting and compelling.


  • I think we're going to see the argument "SOAP is orthogonal to REST" repeated again and again. In the beginning the SOAP adherents were full of disdain against REST, now they want to play in the same playground!

    According to Chris Ferris definition SOAP is "defines a message structure (the SOAP envelope infoset), a set of rules for processing SOAP messages, and an extensibility framework." If this is the new definition, then I would like to hear a simple explanation on how all this baggage helps improve interoperability. Now if SOAP doesn't say anything about interoperability (i.e. it is orthogonal to REST) then a clear consistent and coherent explanation of WS-* would help.


    By Anonymous Anonymous, at March 06, 2005 7:31 AM  

  • Before you try to engage in a discussion with Carlos Perez on a topic in which you think he is not entirely correct, I suggest you read his series on "101 Reasons why Java is better than .NET", and the ensuing debate with Ted Neward.


    By Anonymous Anonymous, at March 06, 2005 1:49 PM  

  • In the beginning the SOAP adherents were full of disdain against RESTThat's simply not true. Look at the W3C XML protocol working group public mailing list, and the www-tag public mailing list, from about this time of year in 2002. There was lots of very respectful listening to people like Paul Prescod and Roy Fielding. This resulted in numerous changes being made to SOAP 2.0. Or look at the W3C Web Services Architecture Note from about a year ago (Chris originally chaired that working group, and I took over later). It doesn't exactly say that REST and SOAP are orthogonal, but treats them as complementary rather than antagonistic.

    Any disdain you may detect comes from annoyance at hearing the same old arguments for three years now, with the Web Services side listening and incorporating some of the good ideas that Fielding and others have expressed, whereas prominent REST advocates are raising the same old issues and once again trying to obstruct a WS spec in W3C, showing no signs of having listened to what the other side has to say.

    Anyway, the "baggage" isn't intended to replace or improve interoperability of plain old XML over HTTP for automated Web applications (e.g. the Yahoo API). The interoperability gains come when one has to deal with multiple transports, encryption, authentication, security, transactions, binding to programming objects, etc. You can happily roll your own POXy / RESTful versions of all this (as eBay has done, for example), but then all your clients have to understand your homegrown schemes. As requirements get more complex, at some point it does become better/faster/cheaper/simpler to leverage the WS stuff than expect people to adopt the REST paradigm (try explaining "hypermedia as the engine of application state" to an ordinary Java developer!)

    By Anonymous Mike Champion, at March 06, 2005 4:27 PM  

  • I don't see the business case for integrating applications over multiple transports, multiple encryption etc.

    Then again, that may be a problem with me; for example, I also don't understand why a sane development team would want to use multiple programming languages to develop services in the scope of the same project.

    I feel the REST way to be more compatible with the object oriented paradigm, too. PUT/GET/POST/DELETE/OPTIONS maps nicely to construct/access/modify/destroy/rtti IMO.

    By Anonymous Ferhat Savci, at March 15, 2005 12:57 PM  

  • Ferhat Savci said...

    "I don't see the business case for integrating applications over multiple transports, multiple encryption etc."

    Let's say the IT system for the Fire service needs to talk to the IT system for the Ambulance service (and the IT systems for a whole bunch of other services that are significant in a crisis). They all use different networks, hardware, security etc.

    By Anonymous Anonymous, at April 07, 2005 8:18 AM  

Post a Comment

<< Home