On Dec 9, 2009, at 8:35 PM, Santiago Pericas-Geertsen wrote:
> Hi,
>
> 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.
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).
I think Link headers and links embedded in entities need to be
supported, and those should be sufficient to declare state
transitions. 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.
Paul.
> -- Santiago
>
> [1] http://wikis.sun.com/display/Jersey/Hypermedia+and+Client+APIs
>
> 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
>