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. 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.
> 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?
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.
IMHO the server-side is rather simple, but i would say that :-), and
it can be summarized in the following four steps:
1) A resource, R say, has a bunch of sub-resources that can modify the
state of R.
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.
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.
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.
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.
> 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.