Loading ...
Sorry, an error occurred while loading the content.

Re: DELETE container?

Expand Messages
  • bhaugen32
    ... Let me see if I understand this correctly yet: Say I have a container of products... http://example.com/products ...containing individual products e.g....
    Message 1 of 42 , Apr 10, 2003
    • 0 Attachment
      --- In rest-discuss@yahoogroups.com, "Roy T. Fielding"
      <fielding@a...> wrote:

      > > 5. How do you DELETE a non-empty container and not
      > > its contents?
      > > My answer: Make it a container of links (see #4)
      >
      > Move the contents first.

      Let me see if I understand this correctly yet:

      Say I have a container of products...
      http://example.com/products
      ...containing individual products e.g....
      http://example.com/products/productA
      http://example.com/products/productB
      ...etc.

      And then I have another collection:
      http://example.com/topTenProducts/productB
      ...etc.

      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?)

      Thanks.
    • Chuck Hinson
      ... It s only annoyting because I had to be reminded again that I have a bad habit of thinking that a resource only exists when a mapping function for that
      Message 42 of 42 , Apr 15, 2003
      • 0 Attachment
        Roy T. Fielding wrote:

        >> So if I PUT to /foo/bar/xyz, there now exists a resource with that name
        >> (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.


        It's only annoyting because I had to be reminded again that I have a
        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.

        >
        >
        > A resource is a source for *future* responses to future requests. Thus,
        > the resource will already exist by virtue of you eventually doing the
        > PUT,
        > 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).



        Despite the poor phrasing of my question, I think you've answered the
        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
        from HTTP).


        --Chuck
      Your message has been successfully submitted and would be delivered to recipients shortly.