W3C home > Mailing lists > Public > public-ldp-wg@w3.org > June 2013

Re: Issue-80: Post media types usable for Create; background for proposal

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Fri, 7 Jun 2013 19:07:58 -0400
To: John Arwe <johnarwe@us.ibm.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
CC: Mark Nottingham <mnot@mnot.net>
Message-ID: <CDD7B368.12A97%erik.wilde@emc.com>
hello john.

seems like i repeated some things you said anyway. sorry for that. some
more remarks:

On 2013-06-07 12:26 , "John Arwe" <johnarwe@us.ibm.com> wrote:
>I proposed a HTTP header because this is part of the interaction model;
>this information does not seem like it's part of the container's state to
>me, although the WG could choose to define it that way.  I also note
>that, had
> Atom defined such a header as I drafted below, LDP could have simply
>re-used it - always a nice test.  Certainly the "use POST for Create"
>pattern is commonly enough used outside of either that the larger Web
>community might find it useful, as long as we're
> careful about the definition.  I think we could define it almost exactly
>as in [patch], so I've pasted that definition in here and made what I
>think are the minimum required changes.

two things that should be taken into consideration:

- link hints (a la AtomPub or generic ones) can be found on links, so you
know them when you follow the link. in order for the header to work, you
would probably need to first do an OPTIONS or something along those lines
to even see it? one more round-trip.

- link hints are in the representation, so when you have something akin to
AtomPub's service document, you can potentially link to various POSTable
resources, and then clients can maybe choose the one that fits their
needs, based on which link hints they see. with headers, this would
require them to poke every single resource with an OPTIONS request.

generally speaking, i don't really like the fact that you're trying to
push application specific semantics (the create) into an HTTP header that
talks about POST. that means that potentially, given that you can do any
number of things with POST, you could end up with any number of
Accept-Post-Whateveritisyouredoing headers, which to me does not look like
a good pattern. this is not going to happen, of course, but i'd like to
point out that Accept-Patch really only talks about the HTTP interactions,
without trying to go any further. in my mind, that's a cleaner way to go
(should we decide to go the header route).

cheers,

dret.
Received on Friday, 7 June 2013 23:08:44 UTC

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