- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Thu, 31 Jan 2013 05:14:55 -0500
- To: Henry Story <henry.story@bblfish.net>, "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
hello henry. On 2013-01-31 9:51 , "Henry Story" <henry.story@bblfish.net> wrote: >On 30 Jan 2013, at 16:23, Ashok Malhotra <ashok.malhotra@oracle.com> >wrote: >>B. To add a container to a container, POST a (child) container >> representation to a (parent) container. >Though there is an issue as to whether the type of the resource should be >specified or not in the HTTP Header eg: >Link: <<http://www.w3.org/ns/ldp#Container>; >rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type" >( AtomXML species these types in their content-type, which is the wrong >place to do that. See: >http://www.w3.org/2012/ldp/wiki/ISSUE-37#POSTing_a_link_to_another_resourc >e ) you seem to have a bit of a misunderstanding how this works in atom. atom only defines application/atom+xml. atompub then added the ;type= media type parameter, because (http://tools.ietf.org/html/rfc5023#section-12.1) it assumed that there cold be different processing models for both kinds of "atom things". the idea of the protocol still is that POSTed resources are self-describing, which means that when you send a <feed>, it's treated as a feed, when you send an <entry>, it's treated as an entry. the protocol even explicitly says that everything has to work as intended even if ;type= is never used. the idea of REST is that you can POST different things to the same URI, and then different things might happen. so it would be perfectly ok to POST both <entry> or <feed> to a <feed>, only that the spec doesn't want to have anything to do with it and says: "This specification does not specify any request semantics or server behavior in the case where the POSTed media type is "application/atom+xml" but the body is something other than an Atom Entry. In particular, what happens on POSTing an Atom Feed Document to a Collection using the "application/ atom+xml" media type is undefined." this means that if you want to support this behavior in an implementation (and there are implementations that do that), then you can simply accept a <feed> (and you might want to make this explicit by listing application/atom+xml;type=feed in the collection's accepted media types, but you don't have to) and build a hierarchical atompub service. the important thing here is to keep in mind that POSTing can mean anything in HTTP/REST: it simply means that what you're doing is neither safe nor idempotent. what else it means depends entirely on *what* you are POSTing, and you can happily POST many different things to the same URI, and then server has to figure out what to do with these things. cheers, dret.
Received on Thursday, 31 January 2013 10:15:49 UTC