Re: ldp-ISSUE-55 (HATEOAS Compliance): Hypermedia as the Engine of Application State (HATEOAS) Compliance [Linked Data Platform core]

hello all.

On 2013-03-15 08:24 , "Linked Data Platform (LDP) Working Group Issue
Tracker" <sysbot+tracker@w3.org> wrote:
>ldp-ISSUE-55 (HATEOAS Compliance): Hypermedia as the Engine of
>Application State (HATEOAS) Compliance [Linked Data Platform core]
>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.

there are several ways in which this could be approached, but i agree that
the current way is not in line with what many REST designers would do
nowadays. the most formal way would be to use URI templates to expose the
query parameters, and then these parameters would be discoverable at
runtime. that's about discovery of interaction affordances.

then there's the question of how to design them. having something like
?firstPage is probably a bit specific, and usually you find designs that
either have well-designed link relations between pages (like the
registered "next" and "previous" link relations
http://www.iana.org/assignments/link-relations/link-relations.xml), or
allow "random access" through value-based parameters that then allow
clients to request specific pages (?page=42). in the latter case, this can
be hardcoded in the media type (because then clients know the available
affordances because they know the media type's design), or it can be made
discoverable at runtime, but the media type would still need to define the
semantics of the parameter, which could then be exposed through mechanisms
similar to home documents
(http://tools.ietf.org/html/draft-nottingham-json-home) or template
descriptions (http://tools.ietf.org/html/draft-wilde-template-desc).

cheers,

dret.

Received on Friday, 15 March 2013 15:49:12 UTC