On the REST verbs vs “processThis” discussion

Since I returned from my unplanned 5 days of holiday, I am only now catching up with my blog feeds. Jim wrote (“REST Advocates in Hit-and-Run Guerrilla Insurgency” and “Bill de h’ra Upbeat, Mark Baker Upbeat, I’m Upbeat?”) about our idea of treating services as entities that only support one imaginary verb called “processThis”, “processMessage”, “receiveMessage”, or something like that (I think that you get the point). Our proposal means that we don’t make any assumptions about what verbs are supported or which “operations” are available at the service end; there is only receipt of messages. Mark Baker seems to like the idea but he also suggests that the use of the extra HTTP verbs is useful when building loosely coupled applications because of their uniform semantics.

“… But when you don’t have to query, e.g. when the endpoint identifier for the service/resource to which you POST that document identifies something stateful, then GET is perfect for retrieving that state (such as the aforementioned seismic data). And of course, URIs makes the perfect endpoint identifier because they’re easily identified and contain all the information you need to grab the data (at least the good ones do 8-), without needing to know how to do a query on them…” [“Jim Webber ambushed by REST advocates”]

I will not argue that one couldn’t build applications using these verbs; the web is a great example of such an application. However, I believe that there is a danger by adopting the resource-oriented view that Mark’s approach suggests. Identifying a resource through a URI and applying the semantics of an HTTP verb on it (e.g., GET URI) is good for retrieving state, as the web demonstrates. My worry about this approach is that there is a coupling of an identifier (the URI), an interface (HTTP verbs), and the state on which these verbs operate. The approach may work for the web but as we attempt to build large-scale, distributed applications that do not involve the human factor, we may get complex networks of references between the states of resources containing references to other resources which, in turn, may lead to brittle applications. We use the same argument against the resource-oriented WS-RF approach, which of course introduces lifetime management, renewable references, etc. behaviours into the picture (borrowed from the distributed-objects world).

Furthermore, I argue that despite the small number of HTTP verbs and their simplicity, they require developers to think only in terms of those verbs and their implied semantics. Our approach seems to provide more flexibility. There are no semantics attached to the imaginary “receiveMessage” and application developers now can focus only on the information that their services exchange and the message exchange patterns they have to come up with.

I notice that we are not that far though. As Mark suggested, after months and months of discussions, we are closer than ever since we agree that the documents exchanged between services are of the most importance.

Looking forward to people’s views.

Update (few minutes later :-)…

While continuing reading my backlog of blog posts, I noticed that Mark had posted some good comments already: “Baby steps on the road to Web nirvana”.

We have been arguing in our Grid computing world arguments for the use of URNs as the means for identifying resources. This is not far from what Mark talks about. However, there is some important difference. URNs are not protocol specific, while URIs carry some protocol specific information. Also, we do not assume a coupling of the identified resource and the means by which the resource can be accessed.

Take as an example the credit card numbers. The way in which the information about the “resource” (the credit card number) is accessed is in no way coupled with its identity. Given a credit card number a service will have some means of accessing the resource. Even the owner could access the information by using the phone, the web, going to a bank, etc. My point is that the protocol used for accessing the information about an identified resource shouldn’t have anything to do with identity of that resource.