- From: Steve Speicher <sspeiche@gmail.com>
- Date: Mon, 6 Oct 2014 09:04:25 -0400
- To: Benjamin Armintor <armintor@gmail.com>
- Cc: public-ldp-comments@w3.org
Hi Benjamin, Thanks for your feedback. I'm following up on this specific thread though, this topic has been discussed on a different thread [1] which I won't repeat here. Hopefully this addresses your comments. [1]: http://lists.w3.org/Archives/Public/public-ldp-comments/2014Sep/0005.html Thanks, Steve Speicher On Wed, Aug 27, 2014 at 9:00 AM, Benjamin Armintor <armintor@gmail.com> wrote: > To whom it may concern: > > I'm working on a REST API specification for a project that is interested in > LDP compliance, so please forgive the late timing of this comment in the > editorial process. > > I believe I understand the intended value of the LDP-Paging spec, but I > think (as an implementor of clients and servers) that LDP might be better > served by the simpler, but more restrictive, approach of elaborating the > HTTP 1.1 Range Request specification to include member and perhaps triple as > Range units. > > The current LDP Paging spec reifies a paged request in a way that is > valuable from a certain perspective of replayability, but unusual in that it > seems to allow the client less control than is typically expected of paged > resources. Consider the following version of Example 3: > > GET /customer-relations HTTP/1.1 > Host: example.org > Accept: text/turtle > Range: triples=1-500 > Prefer: return=representation > > The server might reply with: > HTTP/1.1 200 OK > Content-Type: text/turtle > ETag: "_87e52ce291112" > Link: <http://www.w3.org/ns/ldp#Resource>; rel="type", > <http://www.w3.org/ns/ldp#Page>; rel="type" > Link: <http://example.org/customer-relations>; rel='canonical'; > etag="customer-relations-v1" > Allow: GET,OPTIONS,HEAD > ... > > if the entire representation could be fulfilled, or: > HTTP/1.1 206 Partial Content > Content-Type: text/turtle > Content-Range: triples 1-500/600 > > for a paged response. Alternately, instead of triple limits the client may > just request pages of members: > GET /customer-relations HTTP/1.1 > Host: example.org > Accept: text/turtle > Range: members=1-10 > Prefer: return=representation > > with partial responses: > HTTP/1.1 206 Partial Content > Content-Type: text/turtle > Content-Range: members 1-10/12 > > This approach would be, I think, a much more natural approach to pages of > members- it leverages the HTTP 1.1 features already required of LDP and > makes paging logic more transparent to the client. At first blush it seems > less linkable, but the opacity of a page link in the current spec and the > reliance on additional request headers regardless make its links less useful > than they appear at first blush. It also gives servers and clients > well-defined ways to advertise their ability to process the paged requests > (and types of pages) within the confines of existing REST specifications. > > Regards, > Benjamin Armintor
Received on Monday, 6 October 2014 13:04:55 UTC