Just thought about a useful combination of DELETE and a 201 Created response:
DELETE /service/documents/667 201 Created Location: /service/archive/documents/667 Content-Type: text/plain Document /service/documents/667 has been deleted and archived at /service/archive/documents/667.
As a reaction to the latest experimental proposal for supporting hypermedia in Jersey, Markus chimed in, saying:
If you want to gain all the benefits of REST, you need to apply all four constraints but not just three of them.
I whole-heartedly agree with that.
However, I disagree with his analysis that only the response body (and not the headers) carries the hypermedia that represents the next application state. From a hypermedia constraint point of view it is irrelevant whether the hypermedia controls (that is links, link templates or forms) are placed inside the body or inside the HTTP headers.
Placing the controls into the HTTP header can, for example, be a viable solution when you want to (or have to) use existing document formats for the body that do not provide the ability to place the controls in the body.
The #rest IRC channel (transcripts here and here) has recently become for me a valuable source for thought stimulation (come and visit). Yesterday we had a discussion regarding steady-states and the following observation has been made:
URIs refer to a certain application state; at least in the sense that one can use a URI to go back to a certain application state or that one can pass a URI to another party to bring this party into that application state.
However, ‘that application state’ (despite the notion that I can use the URI to get back to it) is not stable over time. The semantics of the mapping are, but the transitions available form that state can change. So, what is the significance of ‘that application state’?
I have not figured that out yet, but here is a thought I had this morning as a reaction to the discussion:
A Web application comprises a state machine that can change over time. Each state (aka steady-state) of that state machine has three aspects:
The first of the three is constrained to remain stable over time the other two vary depending on the state of the associated domain concept and the actual state machine the server intends to provide to (that particular) client.
UPDATE: It has come up in a number of places a notion of transient states or ephemeral URIs. As far as I understand the issue circles around the idea of giving distinct URIs to different states of application states. With this approach, an order in some ‘review-pending’ state would be represented by a different resource (and hence different URI) than the same order in the state ’shipment-initiated’. Please correct me, if I miss the point here.
My response to that can be found in this comment on Ian’s blog.
I’d highly apprechiate if someone could shed more light on this issue. I think it is a deep one.
This posting to the Jersey user’s list provides more detailed comments, explaining my concerns.
UPDATE: The thread started by the reference above turned out to be rather interesting. It’s worth a look.
Santiago Pericas-Geertsen today wrote about the approach currently taken by Jersey towards providing active server-side support for the hypermedia constraint.
Given the exposure of Jersey I am worried to say the least.
Santiago writes:
It has been identified by other authors that there are actions that cannot be easily mapped to read or write operations on resources.
This quote creates the impression as if there was a problem that needed to be solved and that Jersey will help developers to solve it. This scares me!
It scares me because it looks as if one of the most exposed RESTful HTTP frameworks is about to evolve not on the basis of how to enforce RESTful systems but based on a likely misconception of REST. What we need is to help architects and developers to design RESTful REST systems and not support REST misconceptions by hard coding them into a framework. Apologies if this sounds insulting, I don’t mean to be. I am just worried.
Here is the misconception: with REST, we do not map actions to read or write operations on resources but we achieve coordination between processes by transferring representations. Representations sent from server to client advance the client’s application state and representations that are sent from client to server change resource state. The notions of ‘action’ and ‘read or write’ resources simply do not exist in REST and just because some authors have identified a problem related to these notions should not drive the evolution of JSR311.
In REST a coordination goal is achieved by changing the state of a resource that has the proper semantics. All that is needed is the specification of media types that provide the necessary hypermedia semantics for the client to find such proper resources. RESTful frameworks should encourage the design of proper media types and ideally enforce correct client side behavior instead of introducing a concept of ‘action resources’ that just does not exist in REST.
The primary design artifact for RESTful services is media types, link relations, etc. (there just is nothing else to design) and behind those is very serious and time consuming design work. Pretending that a framework (let alone ‘action resources’) could make this any simpler is misleading.
I guess I have now put myself in a position of having to provide more constructive feedback :-) I’ll give that a try tomorrow.
And apologies again to those people whose work I am criticizing.
UPDATE: Markus Karg chimes in.