- 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>
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