On Feb 14, 2010, at 6:32 PM, Markus Karg wrote:
>
>>> The only difference is: The proposed new API is everything but
>>> RESTful! It is a rape of the RESTful idea by people wanting to enforce
>>> a RPC-style API ontop of REST
>> Instead, the client programmer should *see* the network guts - as ugly
>> as they may be. order.review() hides that we are dealing with remote
>> calls
>
> Even worse: order.review() is a complete misunderstanding of the RESTful
> idea, as the disseration says that a workflow (like reviewing) must be
> controlled (not invoked) completely by the client. This means, it will do
> several calls to stateless servers and keeps track of the transaction, and
> send and receive manipulated state. If the transaction has to fail, it will
> just drop the document. But never will it be RESTful that a server
> manipulates state!
I think the scenario behind the proposal is that the server is an order 'manager' application that manages the orders and invokes other systems to do initiate review and shipment etc. In this sense it is ok that the order is changed - the order is sort of the instance of the business process running on the system.
What I do not understand is why the client should be concerned with triggering that workflow. Wouldn't an 'order manager' application just trigger review and shippment based on some internal rules?
I think the proposal views the client like a workflow engine that calls upon the service to execute some process.
>> [...]
>
> I do not think that people are taking the hypermedia constraint to the
> extreme, but more I think that people have not understood what hypermedia
> actually means: It is not about calling methods, it is about the sole fact
> that inside of the representational state there is also the information of
> what can be done with that. This has absolutely nothing to do with the idea
> of calling a method.
Right. Thinking OO is just confusing the matter. AtomPub uses the term 'protocol operations', BTW.
In my head, I like to think in terms of 'achieved process coordinations' (a system state where the state machines of two processes are aligned). I also like the term 'goal'.
Interestingly, nobody would think of method calling in a message passing environment.
Jan
> For example, if I receive a HTML document that has a
> link in it, and the link allows me to make the server send me a modified
> version of the document (like getting a verified one in contrast to having
> an unverified before), then this is not a method call - but it is a state
> transition, as I get back the same object, but in different state. And
> exactly that is what Fielding had in mind: Let the client examine
> transitions found inside of the hypermedia. Not letting the client finding
> out methods to call. This is REST, not RPC.
>
>>> Guys, that has nothing to do with REST. You just try to do RPC with
>>> http. If you really like to implement that, then please remove the "R"
>>> from the API's name, since that is not REST anymore.
>
> Regards
> Markus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen_at_acm.org
Blog:
http://www.nordsc.com/blog/
Work:
http://www.nordsc.com/
-----------------------------------