Re: URI design, part 2

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 <[email protected]> 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.