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

19206Re: [rest-discuss] URI design, part 2

Expand Messages
  • Max Toro
    Dec 1, 2012
      Did not choose DELETE because cancel does not delete the resource, it
      executes some logic which in the end sets it's status field to
      Canceled.
      The implementation of PATCH with a body 'status=Canceled' can be
      tricky if you also accept changes to other fields, which may or may
      not have some logic associated to them. I think that using a
      subresource as Nicholas Shanks suggested is a good solution, e.g.

      PUT /orders/1/status

      Canceled

      The implementation can do something like this:

      switch (value) {
      case "Canceled":
      cancelOrder(id);
      ...
      }
      --
      Max Toro


      On Sat, Dec 1, 2012 at 2:58 PM, Erik Wilde <dret@...> wrote:
      > hello max.
      >
      >
      > On 2012-12-01 08:17 , Max Toro wrote:
      >>
      >> Thanks for you answer Erik. I don't want to repeat myself, so please
      >> see my answer to Eric, I'd love to get your comments as well. Rather
      >> than good or bad I'd like to determine if my example is REST or not.
      >
      >
      > i guess most people agree that the only reasonable answer to a question such
      > as "is URI X RESTful" is: "tell me more about your design."
      >
      > i'd like to get one tiny bit of clarification from you: when saying you have
      > a resource X/operation, did you choose "cancel" on purpose as something that
      > could be mapped to a DELETE X fairly easily, or do you also consider
      > something such as X/additem, where the hypothetical operation would not
      > delete the resource, but change its status outside of the CRUD realm?
      >
      > thanks,
      >
      > dret.
    • Show all 28 messages in this topic