Like many, I have been pondering the differences in philosophy between REST and SOAP. Other than computational effort and size of the software stack and development effort required to support them, it boils down to a "is it better to structure the world around nouns vs. around verbs" discussion. Last night suddenly an answer came to me that works for me ... it's surprisingly decisive! Well, it surprised me! I wonder whether you'd agree...

To recap, the REST world assumes that the world consists of a gazillion of "resources" (aka "things", aka "nouns") which are accessed with a very small set of verbs (GET, POST, PUT and DELETE or thereabouts). So in order to scale, REST creates new nouns at new URLs, which of course, is very simple and the reason why the web could grow as quickly as it did.

The SOAP world, on the other hand, assumes that the world consists of gazillions of "services" (aka "verbs") which one is able to (or at least is supposed to be able to) connect to each other in many different ways. Nouns do not feature prominently in a SOAP-centric environment, they are simply input and output parameters to the services.

So which one is better, or a better avenue towards the future? There is a fairly similar line of impressive supporters in both camps, so the observer (like me) is left with having to do their own thinking (scary thought, isn't it ;-)).

The answer — well, my new-found answer — lies in realizing that "nouns vs. verbs" is a sloppy version of the actual question. We need to look at the difference of type vs. instance as well. Let's look at the following table of examples:

Clearly, these four fields represent different things. Which are the nouns and verbs of the REST vs. SOAP debate?

The surprising insight here is that in a REST world, we almost always mean "noun instances" when we talk about "nouns", while in the SOAP world, we mean "verb type", not instance. In other words, the table looks like this:

For nouns, nobody ever points a URL to the concept of Payroll (other than for sites that do definitions of things like Wikipedia); we always point to actual instances. Imagine how useful (not!) it were if Fedex URLs referred to the concept of package, rather than particular instances of package (e.g. the package I'm waiting for this morning).

But in a SOAP context, we identify services with types, not instances. Nobody ever points to "To calculate this week's payroll taxes of Acme Inc.", but a URL in a SOAP context identifies a "payroll tax calculating service".

Why is this significant? It's significant because of the vastly different orders of magnitude of how many we have of each. While there are only a handful definitions of the term "payroll", there are millions of instances of it (all the world's companies, multiplied by the number of weeks in a year etc.). This means that while we can use URLs to identify nouns or verbs, in practice, we can use them to idenfify many more nouns than we can use them to identify verbs (because we identify noun instances vs. verb types).

Which brings me back to the original question: which one is more promising for the future? It sounds to me that even if the market share between REST and SOAP was 50-50, there would me many more noun URLs than there would be SOAP URLs (coincidentally exactly what we are seeing out there). Which also means that there are many more opportunities for everybody out there to innovate around nouns, rather than verbs — the nouns are simply more accessible. Which means REST is the innovation platform, while SOAP is less so. On the other hand, if control is your objective, you would be more inclined to build around SOAP. And that answers it for me ... innovation is more likely to occur in the REST world, which thus makes it a more promising platform than SOAP.

By the way, so why is anybody surprised that the open source community tends towards REST and big commercial interests tend towards SOAP?