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.
Criticism is good. We want a good debate about the best way forward, both on the server-side and the client-side proxy. Which is why we chose to be very open about this and why Santiago clearly states:
http://weblogs.java.net/blog/spericas/archive/2010/02/09/exploring-hypermedia-support-jersey
“Note that the proposed API is still experimental and will possibly evolve in unforeseen (and incompatible) ways. Your feedback will be extremely valuable in shaping future versions of this API.”
Hello Jan,
Great comments. I can say that nowadays its much clearer in my mind why such approach should not be the one for rest frameworks.
I believe the link support approach implemented by Jersey started when Restfulie released a no-JSR compatible rest approach. As you mentioned, the first Restfulie example also made available a “pay” method *if* the representation contains a pay link. Later we realized that all relations should be treated as, well, relations. A “payment” relation (as specified by atom if my representation is an atom one), allows me to pay without any problems. A related items relation that points to another atom collection allows items to be POSTED in order to add items to it and so on… everything because the media type defined the semantics of such relations and therefore they are well understood.
I also believe the JSR should not follow the path of early binding and some other decisions as Ive pointed throughout some posts in my blog. Maybe with time passing we can change it? The problem is, or is not, that its a JSR, or a too early specified JSR?
Regards