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.