Paul,
>> I've started a "List of Requirements" section in the wiki [1] based
>> on this mail thread.
>>
>
> Great. I am not sure about requirement 1:
>
> 1) Meta-data about state transitions should not be part of a
> resource representation; instead it should be conveyed in HTTP
> headers or WADL documents, or both.
>
> Certain HTTP headers can be considered part of the representation
> i.e. representation == headers + entity.
If by representation we include headers, then this requirement needs
to be re-phrased. I think the main point is that entities should not
be "artificially" extended to include state transitions information or
other meta-data (as discussed earlier in this thread). I think Marc
has a good point about this.
>
> I suppose it depends on what you mean by meta-data, but typed links
> embedded in XML/JSON will contain data that the client can use to
> decide on whether to make a state transition (for example, HTML
> forms, plus this could get really interesting with RDF).
Do you think typed links are enough to support HATEOAS?
>
> I think Link headers and links embedded in entities need to be
> supported, and those should be sufficient to declare state
> transitions.
Right. I think the point of (1) is that what can go in Link headers
shouldn't be part of the entity.
> WADLs role should be to help identify those links (reproducing data
> where required) in representations such that a client can use that
> at runtime or compile time to aid in the action of state
> transitions, but clients do not have to consume WADL if they do not
> want to.
I agree. Do you want to take a stab at rephrasing the requirement?
-- Santiago
>> On Dec 9, 2009, at 4:38 AM, Paul Sandoz wrote:
>>
>>>
>>> On Dec 8, 2009, at 10:56 PM, Marc Hadley wrote:
>>>
>>>> On Dec 8, 2009, at 2:34 PM, Marc Hadley wrote:
>>>>
>>>>> On Dec 8, 2009, at 2:08 PM, Santiago Pericas-Geertsen wrote:
>>>>>>
>>>>>> I want to make sure I understand and can capture all your points:
>>>>>>
>>>>>> 1) You *don't* think it's a good idea to extend resource
>>>>>> representations to include additional meta-data (using Atom or
>>>>>> otherwise) such as the following example from RESTfulie:
>>>>>>
>>>>>> <order>
>>>>>> <product>basic rails course</product>
>>>>>> <product>RESTful training</product>
>>>>>> <atom:link rel="refresh" href="
>>>>>> http://www.caelum.com.br/orders/1" xmlns:atom="http://www.w3.org/2005/Atom
>>>>>> "/>
>>>>>> <atom:link rel="update" href="
>>>>>> http://www.caelum.com.br/orders/1" xmlns:atom="http://www.w3.org/2005/Atom
>>>>>> "/>
>>>>>> <atom:link rel="pay" href="
>>>>>> http://www.caelum.com.br/orders/1/pay" xmlns:atom="http://www.w3.org/2005/Atom
>>>>>> "/>
>>>>>> <atom:link rel="cancel" href="
>>>>>> http://www.caelum.com.br/orders/1" xmlns:atom="http://www.w3.org/2005/Atom
>>>>>> "/>
>>>>>> </order>
>>>>>>
>>>>> Right. Up till now we've managed to keep JAX-RS at quite a meta-
>>>>> level and I don't think we should be in the business of defining
>>>>> what applications representations have to contain.
>>>>>
>>>>>>
>>>>>> 2) You'd prefer the use of HTTP headers to convey meta-data
>>>>>>
>>>>> Either headers or something like WADL that describes the links
>>>>> already available in representations. E.g. the information in
>>>>> the RESTfulie representation above could be split into data and
>>>>> metadata something like this:
>>>>>
>>>>> Link: <http://www.caelum.com.br/orders/1>; rel=refresh
>>>>> Link: <http://www.caelum.com.br/orders/1>; rel=update
>>>>> Link: <http://www.caelum.com.br/orders/1/pay>; rel=pay
>>>>> Link: <http://www.caelum.com.br/orders/1>; rel=cancel
>>>>>
>>>>> <order>
>>>>> <product>basic rails course</product>
>>>>> <product>RESTful training</product>
>>>>> </order>
>>>>>
>>>> BTW, I think it likely that existing representations could
>>>> include URIs so its equally important to be able to ascribe state
>>>> transition semantics to those without having to change the format
>>>> of the representation.
>>>>
>>>
>>> Yes, the key is not to dictate a particular solution or "style" to
>>> the way state transition links are embedded in representations.
>>>
>>> However, i think It should be easy for the developer to create a
>>> particular style, or latch on to an existing style (the link
>>> header approach in this respect is not so intrusive).
>>>
>>> Paul.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>