2006/5/9, Toru Marumoto <[EMAIL PROTECTED]>:
Please be pationt with me, I'm changing my mind a little...
Let's say, in a introspection document, we have a collection
that accepts "application/atom+xml"(accept both feed doc and entry doc).
<collection
title="Accept multiple entries here"
href="http://example.org/reilly/batch"; >
<accept>application/atom+xml</accept>
</collection>
So, a client POSTs an Atom Feed Document to the collection
(hoping to create multiple entries).
That's not the intended behavior (at least without an explicit
extension): if you POST an Atom Feed Document, you expect the whole
feed document to be a single resource. At least that's what is being
proposed.
If you want to do batching POSTing an Atom Feed Document, you need
some extension (the server telling the client that it allows such
things and the client telling the server that the feed document it is
POSTing is intended to be "batch inserts")
What's the value of the Location: header of the response would be?
I suppose a 207 (Multi-Status) response could work.
http://greenbytes.de/tech/webdav/rfc2518.html#STATUS_207
Multiple Location: headers for each entry created? (I don't think so)
There would be other problems: how will you relate the entries you
POSTed to the entries that have been created? There seems to be
consensus that servers are allowed to overwrite the atom:id (and other
metadata) of the POSTed entries, so there's no mean to identify them
and match them between the request and the response.
So: it's not worth talking about it without any more thinking.
And "batch inserts" can be replaced with multiple POST requests
(either using multiple connections, or pipelined into a single
"persistent" connection –servers MUST send responses in the same order
it received the requests, so you no longer have any problem matching
POSTed entries with created/rejected ones–).
Besides, if a client could PUT an Atom Feed Doc to the collection,
we have a Batch operation...
Contrary to POST, the semantics of PUT are well-defined and are not
meant to "add something" to the target resource but to *replace* the
target resource (or create it if it doesn't exist).
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
This use case suggests (I think) that we should NOT make
"Location header" and "response body as Atom Entry" required.
Presence of the Location header in a 201 (Created) response to a POST
request is a SHOULD per HTTP/1.1
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
--
Thomas Broyer
