Verbs for Doing One Thing Well

One "take away" from this essay by Bill de Hora on the problems is there are significant problems with overloading POST in HTTP as well as falling back to defining new verbs beyond those in WS-Transfer.

Here's the root of the problem with these vocabularies.

I wrote last year...

Every web site that implements custom behavior using forms with GET or POST is an example of the open ended nature of HTTP per se. The architectural style of REST supports the HTTP transport protocol underlying these forms moving across the web, but the application protocol, that is, the behavior of the forms on the client and especially on the server is defined (at least in code) by each specific instance.

Distributed systems wishing to use HTTP, or more generally REST, to perform coordinated work will therefore require some more specifically defined application interface than that provided by REST, or that provided by HTTP.

(Of course I no longer refer to HTTP as a *transport* layer protocol!)

The problem I believe is that the verbs in HTTP as well as in WS-Transfer are attempting to accomodate not only message coordination, but also participant behavior. The problem is developers, if not the specification authors themselves, are thinking of these protocols as communication between a second-class participant (the "client", if you will) and a first-class participant (the "server", if you will).

Our habit is to attempt to overload the verbs of these protocols with our desired "server-side" behavior. This is what happens in the current Web (Web 1.0) where the client is the browser and the server is assumed in most cases to be a database-backed web site. The web site essentially provides the illusion of trees of static pages, but we allow for dynamic update, mostly through forms.

This does not translate cleanly to Web 2.0 with dynamic networks of peers coordinating nearly autonomous actions through semi-structured messages. Overloading verbs such as POST or extending "fixed" vocabularies such as WS-Transfer, as Bill and others have shown, is not "loosely coupled".

The more clean solution I think is to allow each verb in a small fixed set to do one thing well. And that one thing should not be overloaded. Ever.

A good way to do this is to separate message coordination from participant behavior. This requires at least the conceptual or logical separation of the message store (i.e. what was the tree of pages in Web 1.0) from *all* participants, including that participant we want so much to call "the server".

Again, a tuple space is a model for this separation of concerns. The tuple space is the message store. The verbs for coordinating messages into and out of that store never have anything to do with the behavior of any participant. Each verb does one thing well with no overloading and no extension. (There has been a good deal of research into what's the right set of verbs, but the core is pretty solid.)

In this world, the decision of what verb to use for rebooting a machine is moot. The message store is merely a location for storing messages participating in a conversation. If one of those participants choosing to reboot (or reboot something else) then that is the responsibility of the participants in the system.

This side effect is decidedly *not* the responsibility of the verbs used to coordinate messages!