Re: Hypermedia as the Engine of Application State

hello james.

thanks for your comment.

On 2013-03-14 6:18 , James Leigh wrote:
> The description of containers does not read like a RESTful interface. I
> think the specification should follow the REST guidelines closely.
> http://www.w3.org/TR/2013/WD-ldp-20130307/#linked-data-platform-containers
> One possible way to fix this is to:
>        * Remove ?non-member-properties and ?firstPage query token from
>          the spec.
>        * Allow the server to omit some or all container members from the
>          primary resource description (non-member-properties by default).
>        * If some membership triples are omitted a link to the first/next
>          page of membership triples (for each subject/predicate pair)
>          must be present in the response.
> The above still allows small containers to be represented completely in
> one response and still allows paging for large containers. However, all
> representations (all pages) are linked to from the default description.
> By adopting the above the ldp spec would be RESTful.

we are aware of the fact that the current way of hardcoding URI patterns 
is not what we should be doing. it's in there because it was part of the 
original submission, but yes, it needs work.

from the REST perspective, the first question to answer is: do we want 
to have parametrized resource access ("give me page x"), or just fixed 
concepts ("give me the next page").

- for fixed concepts, we should be using the established standards, 
using already existing link relations such as "next" and "prev". these 
links should be exposed in representations on an as needed basis, and 
not (as you correctly point out) be constructed by clients based on 
hard-coded patterns.

- for parametrized access, things get a bit trickier. what you need is a 
way for a client to construct a URI, so that it can ask for page x. for 
this, the existing web standard are URI templates, that allow 
representations to expose templates (containing variables), which then 
are turned into concrete URIs by a well-defined process. templates are 
runtime constructs (one service might expose a page as ...?page=42, 
another one as ?seite=42), but the *concept* of a page as a parameter 
for a URI template is what LDP will need to define.

afaict it is still not clear whether we will just support fixed links 
(avoiding the more tricky URI template approach), or whether we want to 
include parametrized resource access in the first version of LDP. we may 
very well opt for LDP 1.0 to only include simple links (basically what 
RFC 5005 does) and leave parametrized access for the next version.

what's also interesting is the question how to navigate between paged 
and complete representations, should that be something that we want to 
expose. afaik, there are no existing link relations for this we could 
reuse, but it seems like a pattern that might be useful outside of LSP 
as well. bulk/piecemeal or complete/partial could be link relations that 
would allow us to provide link to both paged and complete 
representations, and it would still be up to the container to decide 
what to serve when clients access the container URI (without providing 
URI parameters that might indicate a preference for complete or paged 
access).

thanks a lot for your comments, keep them coming! cheers,

dret.

Received on Monday, 25 March 2013 01:01:58 UTC