Thanks, Thierry. I hadn't considered this from an idempotence point of view, but that makes sense.
Regards Richard Thierry Boileau wrote: > Hello Richard, > > after having a look at the HTTP specification > (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7), a > successfull delete operation is denoted by a successful status (200, > 202 or 204) but at the same time the 404 status expresses the fact > that the underlying resource is here or not. > On one hand we can argue that the effects of two DELETE requests are > the same, thus they can return the same status (in this case the end > status is considered as important). > On the other hand, we want to insist on the fact that the state of the > resource has changed and thus return a successful status at the first > delete and a 404 for the others. > > I'm not sure what is the right answer. It may depend on your > requirements. > > Best regards, > Thierry Boileau > -- > Restlet ~ Core developer ~ http://www.restlet.org > <http://www.restlet.org/> > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > <http://www.noelios.com/> > > >> Hi >> >> I'm testing my system to see how it handles a DELETE request to a >> non-existent resource. I'm expecting a 404 response. >> >> Although I'm flagging my resource as unavailable in the constructor/init >> method removeRepresentations still gets invoked, which means I have to >> explicitly handle the 404 response. >> >> Is this the correct behaviour? >> >> Regards >> >> Richard Hoberman
