Re: hypermedia controls vs. payload

hello alexandre.

On 2013-01-14 20:05 , "Alexandre Bertails" <bertails@w3.org> wrote:
>On 01/14/2013 01:06 PM, Wilde, Erik wrote:
>>- depending on the complexity of your hypermedia format, the number of
>> links in resource representations can be considerable. always placing
>>all
>> of them in HTTP headers as the only option to me seems like an option
>>that
>> quickly may run into limitations of what HTTP should do, and what HTTP
>> implementations are able to do.
>Right. This should be delimited and documented. So far, I've found
>interest only in rel=meta and rel=acl.
>> so my guess is that for some "add-ons" that feel mostly orthogonal to
>>what
>> we're doing (such as the ACL example), using HTTP headers may be a good
>> option and one that allows us to decouple the LDP protocol from
>>orthogonal
>> issues. however, for the things that are at the center of the protocol.
>>i
>> am not so sure that this approach would work very well.
>What are the LDP metadata that would be "at the center of the protocol"?

whatever we want to expose as interaction affordances. hypothetical let's
assume you GET a collection that has many members, and paging allows you
to say to only GET a list of the first 100 members. now you have at least
100 links that you can GET. each of the entries might expose more than one
link, though, for example one link to GET the entry itself, and one link
to GET an entry's content (assuming "aggregation"). now you might have 200
links. and these links are context-sensitive, because the link to an
entry's content must be understood in the context of that entry, otherwise
it's just a link to something random.

my claim was than including these 200 links in HTTP headers wouldn't be
practical, and thus we need a model how these links can be exposed in the
collection resource representation.

thanks and cheers,

dret.

Received on Wednesday, 23 January 2013 15:31:22 UTC