W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: Creation of Containers

From: Richard Cyganiak <richard@cyganiak.de>
Date: Thu, 8 Nov 2012 00:29:22 +0000
Cc: "nathan@webr3.org" <nathan@webr3.org>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Niclas Hoyer <niclas@verbugt.de>
Message-Id: <87DC561E-E9CA-437F-A359-FE8A86D881B6@cyganiak.de>
To: "Wilde, Erik" <Erik.Wilde@emc.com>
Erik,

On 7 Nov 2012, at 23:50, Wilde, Erik wrote:
> just to make that clear: POST is *not* the C in CRUD. thinking about
> REST/HTTP in terms of CRUD concepts usually doesn't help a whole lot. POST
> is the catch-all (anything that isn't safe/idempotent), and media types
> can be designed in a way that you can do many different things by POSTing
> to the same resource, because the request says what you want to do. that
> being said, if your media type somehow depends on "where" you POST things
> (i.e., if you cannot randomly switch around URIs without changing the
> media type's behavior), then you have a pretty serious design issue. URIs
> must be opaque.

All very true. A couple of things though.

1. I don't think that media types are the answer here. In the RDF world, we've never used media types to distinguish anything besides the choice of serialization format for the payload, which inevitably is an RDF graph. The media type doesn't need to tell us any more than that -- how to get an RDF graph out of the bytes.

2. In the RDF world, the semantics of the message is not communicated in a media type but in the RDF vocabularies used within the graph. RDF terms are globally unique, so this is unambiguous, unlike in say JSON where you need media types to distinguish your format from someone else's.

3. I agree that the design shouldn't hardcode where you POST (or GET, for that matter). I dislike the ?firstPage and ?non-member-properties stuff in the current LDP draft. The answer to that can be quite simple though: Just state in the representation where the POST should go. In RDF, that's just a link. The semantics -- “POST here to create a new XYZ”, “GET here to fetch the next page of property values” -- is in the link predicate.

4. This somewhat parallels the situation in HTML, where the interaction semantics are not in the media type but described in the payload -- hyperlinks and forms. Although unlike in HTML, our “forms” probably only need to cover a few hardcoded kinds of actions -- create a new resource in this container, go to the next page, stuff like that.

Best,
Richard
Received on Thursday, 8 November 2012 00:29:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC