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

Deleting an item from a container

Expand Messages
  • Jan Algermissen
    Hi, I am trying to generalize the operations on containers (e.g. queues) and I am stuck with the question of how to delete items from a container. Consider the
    Message 1 of 8 , Nov 19, 2004
    • 0 Attachment
      Hi,

      I am trying to generalize the operations on containers (e.g. queues)
      and I am stuck with the question of how to delete items from a container.

      Consider the following container

      /orders

      with items

      /orders/1
      /orders/2
      /orders/3

      My preferred choice is to invoke DELETE on the item to remove and I
      would like to make the DELETE a GET-and-DELETE operation, partly
      to achieve atomicity of the operation. Looking at the HTTP specs,
      I am not sure if it is ok for the server to return a representation
      of the deleted resource.


      The second issue I am not sure about is whether it is semantically
      ok to use DELETE on a subordinate resource to alter the state of
      the container itself.

      Thoughts?


      Jan


      --
      Jan Algermissen
      Consultant & Programmer
      http://www.jalgermissen.com
    • Josh Sled
      ... A successful response SHOULD be 200 (OK) if the response includes an entity describing the status [...] --- RFC-2616 Sec 9.7 [DELETE] I can read
      Message 2 of 8 , Nov 19, 2004
      • 0 Attachment
        On Fri, 2004-11-19 at 03:52, Jan Algermissen wrote:

        > to achieve atomicity of the operation. Looking at the HTTP specs,
        > I am not sure if it is ok for the server to return a representation
        > of the deleted resource.

        "A successful response SHOULD be 200 (OK) if the
        response includes an entity describing the status
        [...]" --- RFC-2616 Sec 9.7 [DELETE]

        I can read "describe the status" as "describing the [state] of the
        resource at the time of it's deletion". :)


        > The second issue I am not sure about is whether it is semantically
        > ok to use DELETE on a subordinate resource to alter the state of
        > the container itself.

        Surely this can't be too offensive, especially if the server has given
        the client some piece of hypermedia instructing the client that that is
        the proper semantic.

        ...jsled

        --
        http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
      • Jan Algermissen
        Josh, ... I wasn t sure if status referred to the deleted resource or to the returned status code. Or even to the status of the deletion operation (whatever
        Message 3 of 8 , Nov 19, 2004
        • 0 Attachment
          Josh,

          Josh Sled wrote:
          >
          > On Fri, 2004-11-19 at 03:52, Jan Algermissen wrote:
          >
          > > to achieve atomicity of the operation. Looking at the HTTP specs,
          > > I am not sure if it is ok for the server to return a representation
          > > of the deleted resource.
          >
          > "A successful response SHOULD be 200 (OK) if the
          > response includes an entity describing the status
          > [...]" --- RFC-2616 Sec 9.7 [DELETE]
          >
          > I can read "describe the status" as "describing the [state] of the
          > resource at the time of it's deletion". :)

          I wasn't sure if 'status' referred to the deleted resource or to the returned
          status code. Or even to the status of the deletion operation (whatever that might mean).

          I hope your interpretation is possible, but I have the feeling it is just the
          status description...


          >
          > > The second issue I am not sure about is whether it is semantically
          > > ok to use DELETE on a subordinate resource to alter the state of
          > > the container itself.
          >
          > Surely this can't be too offensive, especially if the server has given
          > the client some piece of hypermedia instructing the client that that is
          > the proper semantic.


          Thanks,

          Jan


          > ...jsled
          >
          > --
          > http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >

          --
          Jan Algermissen
          Consultant & Programmer
          http://www.jalgermissen.com
        • luke82rm
          Try to look at: http://www.xent.com/pipermail/fork/2001-August/002923.html it s a link on how to achieve atomicity in a RESTful application. I hope it helps
          Message 4 of 8 , Nov 19, 2004
          • 0 Attachment
            Try to look at:

            http://www.xent.com/pipermail/fork/2001-August/002923.html

            it's a link on how to achieve atomicity in a RESTful application.

            I hope it helps you :-),
            Luke.

            --- In rest-discuss@yahoogroups.com, Jan Algermissen
            <jalgermissen@t...> wrote:
            > Hi,
            >
            > I am trying to generalize the operations on containers (e.g. queues)
            > and I am stuck with the question of how to delete items from a
            container.
            >
            > Consider the following container
            >
            > /orders
            >
            > with items
            >
            > /orders/1
            > /orders/2
            > /orders/3
            >
            > My preferred choice is to invoke DELETE on the item to remove and I
            > would like to make the DELETE a GET-and-DELETE operation, partly
            > to achieve atomicity of the operation. Looking at the HTTP specs,
            > I am not sure if it is ok for the server to return a representation
            > of the deleted resource.
            >
            >
            > The second issue I am not sure about is whether it is semantically
            > ok to use DELETE on a subordinate resource to alter the state of
            > the container itself.
            >
            > Thoughts?
            >
            >
            > Jan
            >
            >
            > --
            > Jan Algermissen
            > Consultant & Programmer
            > http://www.jalgermissen.com
          • S. Mike Dierken
            ... I don t think you need to combine GET and DELETE. The atomicity you are going for is an approach to guarantee that only one client will processes a
            Message 5 of 8 , Nov 19, 2004
            • 0 Attachment
              > My preferred choice is to invoke DELETE on the item to remove and I
              > would like to make the DELETE a GET-and-DELETE operation, partly
              > to achieve atomicity of the operation. Looking at the HTTP specs,

              I don't think you need to combine GET and DELETE. The atomicity you are
              going for is an approach to 'guarantee' that only one client will processes
              a particular item in the queue. There are other ways to do that - perhaps
              using conditional request headers (If-Match, etc.). One issue is that DELETE
              is idempotent - repeatedly sending the request should return a success
              response each time - no indication of the previous state. I think explicit
              state management might be needed here.

              > I am not sure if it is ok for the server to return a representation
              > of the deleted resource.
              http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7 "A successful
              response SHOULD be 200 (OK) if the response includes an entity describing
              the status, [...]"
              This appears to indicate that an entity can be returned.

              >
              >
              > The second issue I am not sure about is whether it is semantically
              > ok to use DELETE on a subordinate resource to alter the state of
              > the container itself.
              If it doesn't break your app or generic client apps, it's likely to be okay.

              There are several relevant discussion on rest-discuss from the past: (we
              should collect these on the Wiki)
              ReST and Representing Mailboxes
              http://groups.yahoo.com/group/rest-discuss/message/3169
            • Justin Sampson
              ... That sounds wrong. The definition of idempotence in the spec is that the side-effects of N 0 identical requests are the same as for a single request.
              Message 6 of 8 , Nov 20, 2004
              • 0 Attachment
                On Fri, 19 Nov 2004, S. Mike Dierken wrote:

                > One issue is that DELETE is idempotent - repeatedly sending the request
                > should return a success response each time - no indication of the
                > previous state.

                That sounds wrong. The definition of "idempotence" in the spec is that
                "the side-effects of N > 0 identical requests are the same as for a single
                request." Side-effects, not responses. If a resource has already been
                DELETEd, I would expect subsequent DELETEs to respond with 404 (and have
                no side-effects).

                http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2

                Justin
              • Jan Algermissen
                ... Yes, that sounds correct. OTH, your posting just made me realize that there is a reliability problem with GET-and-DELETE: If the DELETE request is
                Message 7 of 8 , Nov 20, 2004
                • 0 Attachment
                  Justin Sampson wrote:
                  >
                  > On Fri, 19 Nov 2004, S. Mike Dierken wrote:
                  >
                  > > One issue is that DELETE is idempotent - repeatedly sending the request
                  > > should return a success response each time - no indication of the
                  > > previous state.
                  >
                  > That sounds wrong. The definition of "idempotence" in the spec is that
                  > "the side-effects of N > 0 identical requests are the same as for a single
                  > request." Side-effects, not responses. If a resource has already been
                  > DELETEd, I would expect subsequent DELETEs to respond with 404 (and have
                  > no side-effects).

                  Yes, that sounds correct.

                  OTH, your posting just made me realize that there is a reliability problem
                  with GET-and-DELETE: If the DELETE request is successful, but the response is
                  for some reason not received, the item (e.g. message) is lost.

                  Thus I *have* to go with a transaction controlled GET and subsequent DELETE.

                  Jan


                  >
                  > http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2
                  >
                  > Justin
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >

                  --
                  Jan Algermissen
                  Consultant & Programmer
                  http://www.jalgermissen.com
                • S. Mike Dierken
                  ... to respond with 404 (and have ... Yes, I thought so too. But the meaning of the request is to ensure that when the operation finally completes that the
                  Message 8 of 8 , Nov 20, 2004
                  • 0 Attachment
                    > If a resource has already been DELETEd, I would expect subsequent DELETEs
                    to respond with 404 (and have
                    > no side-effects).
                    Yes, I thought so too. But the meaning of the request is to ensure that when
                    the operation finally completes that the resource is gone. There is no
                    pre-condition that the resource must already exist. This differs from a
                    remote-object approach where there is an implied 'locate object, activate
                    object, invoke object.method()' process.

                    I know I've seen discussion on this, but can't seem to find it now.
                  Your message has been successfully submitted and would be delivered to recipients shortly.