On Feb 15, 2010, at 12:50 PM, Paul Sandoz wrote:
> Hi Jan,
>
> On Feb 15, 2010, at 11:56 AM, Jan Algermissen wrote:
>
>> Paul,
>>
>> On Feb 15, 2010, at 11:46 AM, Paul Sandoz wrote:
>>
>>>
>>> We need to come with a number of patterns that can be applied to use-cases and have corresponding prototype implementations and from all that we will be able to hopefully define really good client and server hypermedia API support!
>>>
>>
>> Recent discussions have made me think that among the more 'advanced' RESTafarians there seem to exist two camps that have a completely different view on how machine-to-machine hypermedia should be designed.
>
> OK. I have a hunch there are probably a number of useful patterns and each may have their pros and cons.
Probably... :-)
> And i do wonder if it also depends on that language utilized to realize those patterns? unfortunately Java can be rather limited when compared to Scala, Clojure or Erlang.
Hmm, I'd actually not think so. Except maybe for parallel requests towards a steady state. Erlang might be more natural in terms of parallelism. (?)
>
>
>> Hence for example my apparent complete non-grasping of what it is you are trying to solve with the Jersey proposal (I just do not know that problem).
>>
>
> Do you think that the current client proxy API is getting in the way the way here? Also, perhaps also the chosen terminology, such as "action" resource and use of verbs, does not help as it has RPC'ish overtones?
Yes, I do think so. OTH, it seems to reflect the thinking of quite a number of people (thinking: Ian R., Jim W.) but I am not sure.
>
> I think the links to Tim, Roy and Bill's blog entries do shed some some light on the motivation for the current pattern as prototyped on the server-side.
Have yet to take a look.
>
> IMHO the server-side is rather simple, but i would say that :-), and it can be summarized in the following four steps:
Yes, server side is simple. Just get the HTTP straight (JSR311 is quite good at that) and jot down your resource implementations. Server side can even be as simple as a shel script started by inetd (hope I am not mixing up the name here).
>
> 1) A resource, R say, has a bunch of sub-resources that can modify the state of R.
Why is that important?
>
> 2) A client may perform a GET on R to retrieve the representation of R, the entity,
> and "be" in the current application state, A say.
Yes - and 'not quite'. The model is that only some resources 'are for' application state When they are retrieved, they send a reprsentation (roy calls it the primary representation) which might instruct the cient to follow a number of other links until a steady state is reached. The steady state is the application state and a steady state may be a collection of several representations. That's what Roy calls the 'current set of representations'.
This is less important from a server side POV but essential for the client side programming model.
>
> 3) That entity will consist of a set of Link headers, L, say, each of which contains a link to
> a sub-resource in 1) and a relationship type. The set L corresponds to the set of valid
> application states the client may transition to given the current application state A.
Huh? Who cares? The steady state contains representations that have media types and these types tell the client what it can achive by traversing the offred transitions. Some links might be to other servers, some might be to other resources outside the current resource's URI space and some might be below that URI space.
The rest is up to the media types and the choices of the server. I don't think a framework should affect/influence these design issues in any way. I'd rather like to see plugins for individual media types that make extracting stuff from representations (of them) easier.
>
> 4) The client may process one of the link headers of L to transition from A to a new application
> state, B say. As part of that transition process the client will refresh the it's application state
> of R.
Again: huh? Who cares? If the server wants the client to refresh, it can do so by sending a redirect or 409 or 303 maybe. HTTP covers all that already. Besides, if you use information of a steady state, the freshness should be taken into account anyhow (Look at TTL header information and.or do a conditional GET - or have the server sort stuff out)
No, I do not think thatthe framework needs to deal with all this at all. Just implement HTTP (but only! HTTP) correctly on the client side.
>
>
> And just to stress the point in big bold flashing neon lights :-) i am not currently suggesting this should be the pattern, or the pattern in it's current form, or indeed the only pattern that developers utilize to implement hypermedia support for their use cases (as Marc has already pointed out we want to make it easier to embed links in entity bodies). It is just the first, simple, concrete experiment we have done, based on others similar experience (Sun Cloud API), to try and make progress (knowledge and understanding) in this area towards a good solution in Jersey and towards good input into any new JAX-RS effort.
Understood. Sun Cloud API is not a REST API, is it? I do not image (though have not looked at it) that they provide a bunch of media types that specify the semantics, do they? If they don't, it is at best an HTTP-based API.
Jan
>
>
>> I have brainstormed that here a bit: http://www.nordsc.com/blog/?p=358 and make sure you follow the links and read about Mike Amundsen's 'transient URIs' and Ian S. Robinson's 'ephemeral URIs'. Please also read my comment on Ian's blog (once he moderated it). My thinking likely only comes across in the complete context.
>>
>
> OK.
>
> I must admit to finding it very hard to reason about all this in the abstract. I need concrete prototypes to play with and iterate on :-)
>
>
>> I have a hunch that a) there is a very important aspect behind the 'divide' and b) it is vital to understand each other and reach a real conclusion (wrt Jersey especially).
>>
>
> OK.
>
> Paul.
>
> ---------------------------------------------------------------------
> 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/
-----------------------------------