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.