On Wed, Mar 16, 2011 at 10:52:27PM +, Richard Jones wrote:
6.5. Deleting the Content of a Resource
Should return the 200 header representing what has happened.
I'm against the delete operation on the content URI returning the receipt
of the edit-URI.
No one asked for this, the client asked for the thing to be deleted, not a
statement or
receipt! I've made this point before... it got ignored.
Oh for god's sake Dave, grow up. It did not get ignored because you and
I had a long discussion about it in person. I argued that since all the
other operations can optionally supply a response to a DELETE request,
it was inconsistent to not be able to supply one in this one instance.
Additionally, the deposit receipt is strictly optional in ALL cases as
per the specification. You argued that DELETE doesn't allow a response
(and should return 204), and this turned out to be untrue when I pointed
you to the HTTP spec. I'd appreciate it if you'd actually remember the
discussions we've had about this before having a strop.
FWIW, in our data repository implementations, some collections use Atom
tombstones [1,2], and some don't. For collections that use tombstones, a DELETE
request will return a 200 with an at:deleted-entry as the response body. For
collections that do not use tombstones, a DELETE request will return 204.
So I believe it is reasonable to return some content in response to a DELETE
request. Whether you should or not will depend on what the client needs. I
remember seeing some ideas around clients being able to express a preference
for 204 or 200 in response to DELETE, but I don't know if that went anywhere.
Cheers,
Alistair
[1] http://tools.ietf.org/html/draft-snell-atompub-tombstones-12
[2] http://code.google.com/p/atombeat/wiki/TombstonesDesign - ignore the stuff
about ghosts, that's probably going to change
The client knows the edit-URI as as you say in your video Richard, if you
do a get on the
Edit-URI you can get the receipt again. This is too overblown here.
It's strictly optional as per the document. If you don't want to return
a receipt in your implementation, then don't.
1) Client asks to delete object at any URI
2) Server returns http error code
If the server chooses to return anything else then the Content-Location
header MUST be
used to define what it is returning. This is because the client SHOULDN'T
be able to call
the same delete operation to get the same content as the object should 404
or 410 at
that point.
I will add the requirements on the Content-Location header to the spec
if that's the appropriate thing to do. I'm still a little unsure about
how Location and Content-Location should be used ... have to go do some
more reading of the HTTP spec.
6.6. Adding Content to a Resource
Yuck! This section needs completely re-writing and/or removing. There is no
detail
here on what the server should do with the random content it is given and
where it should go.
If it is posted to the Edit-URI, is the a new EM-URI, replace everything at
the EM-URI or
what. I think if you want to add content (Media) into the container then
you post it to the
Edit-Media URI.
POST to the EM-URI implies something about the structure of the Media on
the server. POST to the Edit-URI is the appropriate RESTful way to add
new content to a container.
There is no detail on what the server should do because SWORD is an
interface definition not a set of implementation decisions. How the
server implements a POST of new content to the container is up to the
precise mechanisms of the application ...
I really don't like this and think we should more closely consider GDocs
API here for
how to handle containers and the limitations.
We have tried to ensure that the GData spec is not ruled out by SWORD,
but it brings with it its own set of idioms with regard to hierarchical
file systems which may be appropriate for EPrints, but is not
necessarily appropriate for all other scholarly information systems. As
such, I'm reticent to propose it as /part/ of SWORD but I do want to
ensure that you can implement it /as well as/ SWORD.
I spent some time working through the GData 3.0 spec and was unable to
find any information about exactly how they think you should get hold of
the feed representation of an entry. I have assumed content negotiation
on the Edit-URI (see Section 6.8), but if you could confirm for me how
Google recommend this is done that would be useful.
This whole fudge it and see it not going to help in the future.
this doesn't appear to be a sentence. can you reword/expand?
Interestingly section 6.6.3 DOES use the EM-URI not the Edit-URI...? Any
reason?
Typo, by the looks of it, I will fix that.
Other than that, this looks pretty good. I still believe it can be made
much better
through better alignment with the GDocs
