On How to Get a Cup of Coffee

InfoQ has recently published a How To Get a Cup of Coffee article about RESTful services.

I did like reading the article : it talks about workflows, shows with the help of state diagrams how clients actually drive and execute applications and overall it entertains the reader so I'd like to join those who welcomed this article. It was the only technical article I read last week, on vacation, and I was nearly killed when I was spotted reading it :-)

What surprised me a bit though is what the authors say about clients discovering which method, say PUT which may be invoked on a given resource service. For example :

"to find out if we can change the order, we ask the resource what operations it's prepared to process using the HTTP OPTIONS verb, as shown on the wire in Figure 6." - please refer to the original article to see Figure 6.

Next :

"From Figure 6 we see that the resource is readable (it supports GET) and it's updatable (it supports PUT)."

I think this use of OPTIONS is of no practical use at all. I agree it does show what OPTIONS can be used for but I find it difficult to imagine a compiled client code checking how a given resource can be updated, especially given what is said next in the article :

"Although partial updates are the subject of deep philosophical debates within the REST community, we take a pragmatic approach" and (authors) decide to use PUT to do a partial update. Big +1 on the pragmatic approach by the way.

In meantime Mark Nottingham provides some insightful comments but again this comment on the use of PUT for partial updates catches my attention :

"This is a flagrant abuse of the semantics of PUT; if you want to combine a representation with the existing state of the resource, use POST or the emerging PATCH. "

To me it all means only one thing : the RESTful HTTP-aware compiled client code is as tightly coupled to a given resource with a generic HTTP interface as the client code generated from either WSDL or WADL is. One service will use PUT, the other one will do POST and the 3rd one will use PATCH - but the knowledge of the verb to be used when doing a given type of update is embedded in the client application code - unless it's a totally generic client application, say a browser handling HTML forms.

Here's one more excerpt from the article.

"Consumers typically agree the semantics of representations and transitions with a service during design and development. But there's no guarantee that as service evolves, it won't confront the client with state representations and transitions the client had never anticipated but knows how to process – that's the nature of the loosely coupled Web. Reaching agreement on resource formats and representations under these circumstances is, however, outside the scope of this article."

I'm curious what can be said about reaching agreements under these circumstances ? I'm seeing the client codes being recompiled in these cases if the newly introduced data or semantically important links are to be noticed.