On Feb 10, 2010, at 6:40 PM, Paul Sandoz wrote:
> On Feb 10, 2010, at 4:21 PM, Jan Algermissen wrote:
>> The only RESTful way to approach this is
>>
>> - GET /orders/2
>> - dispatch on whatever media type we received (or on available headers)
>> - if have-link-header 'pay' OR media type == application/order AND have pay-link in the representation THEN (and only then)
>> - do a POST on the target of the pay link (we know this from corresponding spec (and maybe form in representation))
>
> The intent of the proxy implementation is to do something similar to the above (but only link headers are currently implemented). But it still needs better error handling.
Hmm, sorry. I do not understand how the proxy approach tries to deal with several possible returned media types. I understand it to provide a way to react upon/consume one particular kind of representation.
What do you mean by 'error handling'? Can you provide an example for an 'error'?
>
> Have you tried playing around with the example?
I looked at the docs <
https://jersey.dev.java.net/nonav/documentation/1.2-SNAPSHOT/user-guide.html#d4e1013> but I guess I just can't see what the problem is that this is trying to solve. (But then, I find the whole aproach to hypermedia confusing (sorry)).
Jan
>
>
>> - GOTO handle next state
>> - if media type == [something else]
>> - try out some other rule to persue the goal of 'paying'
>> - if 4xx
>> - handle 4xx
>> ....
>>
>> The issue is that REST does not allow us to view one particular representation as the 'correct' server behavior and the others as 'failures'. Even 4xx responses must be considered part of the normal conversation between client and server.
>> It may be hard to accept, but anything else would not be REST. With the result that server owners have to know what their clients are assuming besides hypermedia semantics.
>>
>> My deepest concern is to get this point across to developement teams (that do not have the time to dive into REST too deeply) and order.pay() simply works against that goal because it makes it look as if there was any guarantee that that link will be available. There is no such guarantee in REST.
>>
>> And try..catch around order.pay() would not be helpful because it would even more emphazise the idea that of order.pay() failung being an *exception*. It is not in REST.
>>
>
> That is API design and is orthogonal to REST itself.
>
> IMHO i think we may be discussing API design and how that may promote RESTfulness, rather than REST per say (which i think we all have a fairly good grasp of).
>
> Exceptions can be an effective way of handling failure states (the Jersey client API already uses such a pattern).
>
> Although as you say there are no guarantees there are good probabilities that a documented service will not break clients by removing documented features e.g. a link, of the payment type, MUST be present in the representation for application/order+xml. Hence there may be value coding for the probably case and managing errors with exceptions.
>
>
> One issue with the current proxy approach is it cannot determine whether link, of a certain type is present or not, for optional cases, except via catching exceptions or looking into the representation headers or entity (no support yet for XPath queries).
>
> A criticism i have of the current proxy approach is that all link types (actions) are declared, calling some may result in failure because the state is not valid, and the client needs to know in what order to call, which is the case anyway regardless of the approach for machine to machine communication, but splitting up the controller interface into separate link type interfaces, with transitions method to other link type interfaces, may better help guide the developer appropriately through the state machine.
>
> i.e. i think may prefer to see separate proxy interfaces for media types and link types (the stuff that the client binds to).
>
> Paul.
>
>> Phew - hope you can figure out from that what I am trying to say.
>>
>> Jan
>>
>> [1] Let's for now not tackle the question what that means.
>>
>>
>> -----------------------------------
>> Jan Algermissen, Consultant
>> NORD Software Consulting
>>
>> Mail: algermissen_at_acm.org
>> Blog: http://www.nordsc.com/blog/
>> Work: http://www.nordsc.com/
>> -----------------------------------
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> 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/
-----------------------------------