Re: DELETE container?
- --- In email@example.com, "Roy T. Fielding"
> > 5. How do you DELETE a non-empty container and notLet me see if I understand this correctly yet:
> > its contents?
> > My answer: Make it a container of links (see #4)
> Move the contents first.
Say I have a container of products...
...containing individual products e.g....
And then I have another collection:
Would I need to move the products under topTenProducts before I
DELETE the topTenProducts collection because
http://example.com/topTenProducts/productB is a different resource
than http://example.com/products/productB ?
Even though they are the same product? And that the
physical "resource" behind the covers is the same?
Is there a name in REST-speak for that physical thing behind the
covers that is the same?
(Or am I still thinking incorrectly about this REST stuff?)
- Roy T. Fielding wrote:
>> So if I PUT to /foo/bar/xyz, there now exists a resource with that nameIt's only annoyting because I had to be reminded again that I have a
>> (assuming all goes well). Does that necessarily imply that there is now
>> also a resource named /foo/bar? That is, if I start with an empty
>> hierarchy and no resources, then do a PUT to /foo/bar/xyz, is there
>> anything about REST or HTTP that dictates that I now have three
>> resources rather than one?
> What is a resource? What makes you think it didn't exist before the PUT?
> Yeah, I know that's an annoying answer, but it is quite pointless to be
> discussing these things if we aren't even clear on what is a resource.
bad habit of thinking that a resource only exists when a mapping
function for that resource has been implemented and is able to respond
to a request with something other than the equivalent of a 404.
>Despite the poor phrasing of my question, I think you've answered the
> A resource is a source for *future* responses to future requests. Thus,
> the resource will already exist by virtue of you eventually doing the
> and what you are doing with those requests is changing the responses
> to future requests. Whether or not those ancestral names, or any other
> names that might have been created by the usual side-effects, are
> accessible to future requests (and hence are resources) is defined by
> the server and not by the protocol (or even the style).
> The server might choose to reject the PUT request simply because it
> wants access control to be specified first. Interoperability is
> obtained not by restricting the behavior of the server, but by
> requiring that the server respond according to its desires and
> enabling the client to understand that response.
> One of the keys to understanding how REST works is to understand that
> the implementations have no clue what the resource is or how it is
> defined or what, in fact, makes it a resource. That is just too hard
> a concept for the implementations to handle. Even the human beings
> maintaining the site have a hard time figuring that one out, because
> we just aren't very good at predicting the future. In contrast,
> it is relatively easy to talk about representations, storing them
> and mapping them to names that are resources, since those are
> operations that manipulate bits in the "now" and are easy for
> server mechanisms to understand and implement.
> Thus, it is not necessary to know what the fate of /foo/bar/ might
> be after a
> PUT /foo/bar/thing
> even though we do know what its fate will be after a
> DELETE /foo/
> has successfully completed. Note, however, that the success of the
> first request does not imply that the server must allow the second
> request. It may choose to forbid it (for any reason).
question that I intended to ask. As I understand it, then, neither REST
nor HTTP dictate the existance of any sort of relationship between
/foo/bar/thing and /foo/bar/ other than name containment (and that only