In his post on the states and transitions of a resource he claims that REST has no way to let a client know what state transitions are available for a given resource....
Um, what is hypermedia?
Distributed hypermedia provides a uniform means of accessing services through the embedding of action controls within the presentation of information retrieved from remote sites.This quote is just the introduction to hypermedia and REST, but we already have an answer.
Action controls are embedded. Action controls are embedded.
Embedding the action controls means
- The client doesn't need to have generated (and hard-coded) client stubs.
- The server can change it's rules and expand available states as needed.
- The client does need to process a generically extensible content type.
Perhaps more directly on point is this quote from 5.3.3 Data View:
The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations.Jean-Jacques' answer to how to share types, constraints, correct states, and transitions is not suprisingly: a schema and a business interface. Let's take those four goals one at a time:
- Types: definitely covered by IDL (until the systems changes then you need to tell everyone to re-compile...)
- Constraints: Not even covered a little by todays SOA technologies. Until there is an OCL or Catalyis (or Z or ...) model that get's compiled with WSDL the best a schema and business interface will have for constraints is a few lines of prose... (in <!-- XML comments no less!! -->)
- States: WSDL is not much help, maybe you can infer the states from the operation names? SSDL I think actually does cover this...
- Transitions: Same as states; how do we deduce which operations are transitions?
Static class diagrams (WSDL) and code-generation are so much more in my control and experience. If only they worked for distributed systems without so many negatives...
The complete ignorance of hypermedia and FUD in the blog posting compelled me to respond and put my $.02 in.
5 comments:
Hi:
do you read my arguments? Can you tell me how a server receiving a link is supposed to make sense of it?
Yes a user seeing a link in a browser can make sense of it because there is an implicit shared semantic space between the resource designer and the user.
JJ-
JJ,
(I'm going to assume you meant "how a client receiving a link" and just made a typo. If that isn't a valid assumption correct me...)
Thanks for commenting. I re-read my post and think I should have put *rant* markings around some of it - it sounded to harsh.
To answer your question: the machine client can apply processing logic to the data, links, and forms that are present in the representation. Most significantly the links and forms can also be marked with processable data to support machine processing.
I described a trivial HTML microformat for shopping that I intended to intuitively (not formally) demonstrate what I mean in a previous post here.
The quick metaphor I used was "signposts" encoded into the class attribute of HTML elements. If a machine client wanted to checkout and purchase something it would look for a form with class="checkout" and fill it in with what it could match up. Based on the next representation the client would then try again, X times, until either the multi-step process succeeded or failed.
For the record I consider RESTful machine clients, and coding clients to this style, to be the most difficult and arcane issue facing would-be REST systems architects. The theory is all well and good, but I find the practice to be very far removed right now. The simple microformat I described could be encoded into an XML namespace or even as RDF data (see Simple Web Services for draft work towards a similar end.
One final comment: A hypermedia exposed resource can much more easily only present the right transitions to a remote client. For example a WSDL based AccountService would expose a transfer(..) operation even for closed Accounts, but a hypermedia representation wouldn't include a [form class="transfer"]....[/form] for closed accounts. This is a more useful exposure of resource state than most OO system and is a usefully exploitable characteristic for simplifying distributed systems that WSDL and distributed objects don't/can't take advantage of.
Regards,
John
John:
thanks for these clarification. This question is emotionally charged and I don't mind people expressing their emotion, as long as we use logical arguments in the end.
I meant a "server acting as a client" as opposed to a "human as a client". So I think we are speaking about the same thing.
In this post: http://johnheintz.blogspot.com/2007/05/does-rest-need-dl.html
you say:
>> But wouldn't it be so nice to have one! Sure, until you want to change anything. A DL couples the client to the server, and forces stability of everything defined by the DL.
>> The REST style encourages loose coupling, independent evolution, and uniform interfaces.
>> How is a DL so bad? A DL is used to generate code (stubs/skeletons) at design time. After that, any changes to the URI or data values on the server side will brake any clients.
We are at the heart of the question, the question I am raising to the REST community is "do you think a resource has actions?" Can you write a meaningful application without resources and without actions? My whole argument is that when a human is a client, it can intuitively make sense of the actions because it can understand the semantics of the resource designer.
However, when a server is now the client consuming the resource representation it does not have the same shared understanding. Whether you use a DL or not, I would like to argue a server (acting as a client) has its own understanding of the resource actions. For instance, let's go back to the Job Application resource that I use. What is its real interface?
- GET - no problem, I can GET a representation of this resource as often as I like, as long as I have access rights
- PUT - ok, I can change the content of this resource put it, ah but wait
- submit, why is submit different than PUT? I can't PUT anymore (if I am the condidate) once it was submitted. Now whether you thing of submit as a WSDL operation or a combination of (Verb=PUT, Property=//@submitted, Value=True) I argue it is the same, there is no difference between these two representations because an action is an action. The State of a Resource is fundamentally different from its content.
PUT has an "idempotent" feel to it (it is no IDEMPotent of course), but I can PUT as long as I want (as I long as I am authorized). However, when I call an action on the resource and this action successfully transitions the resource to a different state, in general I can no longer invoke this action - ever. In this case, once the application is submitted, it is. The Recruiter can "PUT" some more content on it, but when he or she calls the action "- reject", he or she can longer "PUT" more content to the job application resource.
The fundamental question is not about REST or WS-*, the fundamental question is how do we build applications (actually here information systems).
This article: http://www.infoq.com/articles/seven-fallacies-of-bpm will air tomorrow morning. It should give more precisions on an "assembly" mechanism that make action interfaces composable, therefore bringing some level of loose-coupling to what you are acustomed to.
I am also preparing two more articles on the subject.
I repeat, again and again, an action interface does not make REST bad. The designers of the Web understood that they had to make the actions seemless to enable the web. If they indeed had this goal and achieved it consciously with REST, these guys are beyond brilliant (they are anyways), but it is not because they made the actions seemless that 'actions' have disappeared. These semantics are still there, along with the semantics of a trans-action (two or more resources must transition to a new state or otherwise all return to their original state).
>> A hypermedia exposed resource can much more easily only present the right transitions to a remote client.
yes, I agree with that, especially if the client is a human, but also if the client is a server provided they share an ontology, but it is a lot harder in the case the client is a server.
>> For example a WSDL based AccountService would expose a transfer(..) operation even for closed Accounts, but a hypermedia representation wouldn't include a [form class="transfer"]....[/form] for closed accounts.
yes, absolutely agreed, but I think we both agree that in the underlying application mode, REST or no REST there is something called an action and the client (human or server) cannot ignore these actions. I totally get that REST is very smart at exposing the right set of actions all the time, without ever really requiring to expose an interface.
I am just asking if you could please
a) transpose all that you are saying to a server as a client
b) consider the "assembly" mechanism as a way to achieve decoupling between interfaces.
JJ-
John:
one more thing, note that we are in a funny situation: REST has the concept of resource and WS-* the concept of actions, so IMHO, neither REST or WS-* is really complete.
I really want a stack where I have resources, actions, trans-actions,... and a few other things.
JJ-
JJ,
This is an ironic and lively discussion :)
You commented that this is a charged question, I agree.
The comment that originally triggered my reactive post was this:
"the irony is that Representational State Transfer cannot efficiently deal with the state changes (content and lifecycle) of a resource."
If you would allow for this re-phrasing than I think we may agree more than we disagree (yes, really! ;)
"REST provides for the exposure of resource state changes with significant server-side expressiveness, but there is little or no client-side guidance or experience for automated (machine) clients."
I'm going to put this into a separate post (if only to get more access for formatting).
John
Post a Comment