Re: LDP would benefit from being RESTful

On Mon, Nov 19, 2012 at 12:14 PM, Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote:
> Mandag 19 november 2012 01:23, skrev Martynas Jusevičius:
>> It is workable as the example was a simplified state machine version
>> of Graphity LDP implementation :) Take a look here:
>> https://github.com/Graphity/graphity-ldp
>> I've been doing Linked Data client work on this platform for a while now.
>
> Very cool! Indeed, practical implementations go a long way to prove the
> workability. I just haven't gotten very far with my own implementation
> yet. :-)

I haven't had time to implement write operations yet, but it's a
question of how JAX-RS @POST/@PUT/@DELETE methods map to Jena's
OntResource add(Model) and remove() etc.

>
>> > However, I think it is important to have write operations explicit, so
>> > that clients doesn't have to just guess what they are allowed to
>> > expected to do, as that wouldn't scale if many operations are possible.
>>
>> It is important, but with HTTP clients don't have to guess -- there is
>> the OPTIONS method that shows available methods for a resource:
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2
>
> Yup, and AFAICS, the current spec has the Allows header on HEAD (why not
> GET?).
>
>> If we define the Linked Data CRUD operations unambiguously and
>> generically as HTTP methods, then the resources become self-describing
>> during the whole read/write lifecycle. I think the best way to achieve
>> this is to keep as close to the HTTP semantics as possible, that's
>> what I tried to do in my post.
>
> Actually, I think the opposite: I think it is important to keep as close to
> what people actually expect to do. I.e. rather say something with "ex:put",
> say "ex:replaced", since what you do when putting to a resource that
> already exists is to replace it.

I think ex:replaced and similar metadata belongs to provenance, i.e.
metadata about previous versions of the state. Provenance adds another
(ideally, transparent) level of complexity. I think we should start
with how the current resource state is changed, without thinking about
preserving previous versions, just making sure current changes are
consistent.

Why I'm arguing HTTP is perfect for that... well, isn't HTTP what
works and what the Web is built on? Its semantics are well-defined and
implementations abundant. Adding a new vocabulary to augment HTTP
state changing semantics would be superfluous, it would just make the
LDP uptake very hard.

> There are mainly two reasons for that: One is that it isn't *immediately*
> obvious. You have to do another HTTP request, which is one of the things
> people are troubling with with the whole 303 thing, even though their
> client does it automatically... I think a good guiding principle is that if
> you have the representation of a resource, you should know what you can do
> with it.

Yes, I saw that point coming :) But how do you retrieve the
representation of the resource in the first place? Presumably by GET
method?
What if the resource is, say, write-only, and the GET method is not
allowed? You would either have to invoke OPTIONS and check the
available methods first, or invoke GET right away and fail. You can of
course use the representation you had cached earlier, but that can
very soon become obsolete and inconsistent with the current resource
state and capabilities (such as allowed HTTP methods).

In other words, you generally cannot avoid this round-trip anyway, and
again HTTP plays the crucial role here.

> The other thing is that you can't describe it any further, i.e. you can't
> define what you mean by a method: Something that the WG has to resolve is
> e.g. what it means to POST, does it mean that you do an RDF Merge of the
> payload into the resource, or does it mean doing a Union between the two
> graphs? OPTIONS can't tell you that, but an RDF vocab can trivially (thus
> hm:mergeInto in my example). Stuff like that has to be in the message for
> the protocol to be RESTful.

I think that is exactly what the LDP WG should be doing: define how
HTTP methods map to RDF graph operations, generically and
unambiguously. They have to explicitly specify the "what it means"
part, so we can rely on HTTP only and avoid vocabularies for this
purpose (for reasons explained above). If you read the HTTP method
specifications, they already have some good indications:

POST is designed to allow a uniform method to cover the following functions:
      - Annotation of existing resources;
      - Posting a message to a bulletin board, newsgroup, mailing
list, or similar group of articles;
      - Providing a block of data, such as the result of submitting a
form, to a data-handling process;
      - Extending a database through an append operation.

The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified
version of the one residing on the origin server. If the Request-URI
does not point to an existing resource, and that URI is capable of
being defined as a new resource by the requesting user agent, the
origin server can create the resource with that URI.

Is it only me who sees POST as appending the RDF graph (server mints a
new resource URI if needed), while PUT can be used to create or
replace a resource with request URI and its RDF description?

> Moreover, well, I guess it is a rather contrived example, but I couldn't
> come up with a better right now: Say you have a pizza representation: You
> could then just order it, or you could add more toppings, both resulting in
> PUT operations. You'd like to describe the distinctions, but again OPTIONS
> can't do that, RDF can. Though, I admit that it would be better to come up
> with a real, distinguishing use case. :-)

You don't have to work on the same pizza URI and the same
representation to achieve this, do you? If "pizza order", "pizza", and
"pizza toppings" are different concepts, then they might (and probably
should) have different URIs, different representations, and implement
different HTTP methods.
If there is something more specific you need to express, you might use
the pizza and/or e-commerce vocabularies -- which your client likely
understands, if it is dealing with pizza orders?

If we could reformulate the pizzas into a software bugs, then we could
extend my initial example and cover more use cases :)

Martynas
graphity.org

Received on Monday, 19 November 2012 12:41:05 UTC