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

Hi Erik,

"Wilde, Erik" <Erik.Wilde@emc.com> wrote on 05/10/2013 09:52:13 AM:

> From: "Wilde, Erik" <Erik.Wilde@emc.com>
> To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, 
> Cc: Arnaud Le Hors/Cupertino/IBM@IBMUS
> Date: 05/10/2013 09:52 AM
> Subject: Re: Proposal to close Issue-65: FirstPage HATEOAS Compliance
> 
> hello arnaud.
> 
> On 2013-05-10 9:18 , "Arnaud Le Hors" <lehors@us.ibm.com> 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
> >http://www.w3.org/ns/ldp#:firstPage) 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).

This is what I'm proposing. The link would be on the (full) resource, so 
that a client could find it with a HEAD.

> 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.

I agree that if we chose to handle the first page via an HTTP header it 
would make sense to handle the next pages the same way.

> 
> 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.

I'm aware of that possibility but that seems to be a lot more complicated 
so I favor the simpler solution of a link header.

> 
> cheers,
> 
> dret.
> 

Thanks.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group