Re: Proposal to close Issue-65: FirstPage HATEOAS Compliance

On 5/10/13 12:52 PM, Wilde, Erik wrote:
> hello arnaud.
> On 2013-05-10 9:18 , "Arnaud Le Hors" <> wrote:
>> 1) Keep that in response to a GET, LDP servers MAY redirect to a resource
>> that only contains the first page
>> 2) Remove built-in URL pattern <resourceURL>?firstPage
>> 3) Add that when LDP servers provide a resource that only contains the
>> first page they may advertise it via an HTTP Link header rel=first (this
>> is defined by IANA, alternatively we can define our own a la
>> on the resource.
>> The latter (3) is only necessary if we want to retain the capability for
>> a client to initiate paging. I think this is simple enough that it's
>> worth considering but if this gives anyone heartburn or if it requires
>> additional
>> discussion for which we have no time I say drop it and close with (1) &
>> (2). We can always add (3) later.
> agreed that (3) could be optional (in the same way as RFC 4287 and 5005
> are layered). however, a "first" relation should be used to link *to* the
> first page (from a page *other* than the first page). for HATEOAS, you
> would want to have relative paging links with "next" and "previous", so
> that clients could follow those links to navigate between pages. that
> would be an easy first step towards hypermedia affordances.
> a more sophisticated design would be to use URI templates and allow
> clients to request specific pages, but then you would want to advertise
> the URI template and expose the variables in it, so that clients could
> request representations with explicit values for things such as page size,
> or page number.
+1 for the more sophisticated approach. We actually use that approach in 
some of our endeavors.

> cheers,
> dret.



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Friday, 10 May 2013 17:05:36 UTC