3 ms·
It would really depend on the semantics of the booking and the system. Another alternative would be DELETE /booking/:id Which is basically a more correct
by bodhi 15y ago
It would really depend on the semantics of the booking and the system. Another alternative would be
DELETE /booking/:id
Which is basically a more correct HTTP version of your last option. Otherwise, I would lean towards your second option (the PUT), as I would think that what you are doing is telling the server what you want the state of the booking to become. What happens server-side based on the PUT isn't really your concern as a client of the API.
> more specifically we want to trigger the "cancel" action
I'd posit that this is actually something that the API user shouldn't need to care about.
Good question though, I've often pondered it myself.
- artsrc 15y agoI think that a canceled booking is still a booking, just a cancelled one. Here is wording from the HTTP spec "However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location. " I don't expect the server to move the booking to an inaccessible location so I see this as a state change not a delete. Hence I am thinking PUT, not DELETE.
- bodhi 15y agoExactly, it depends on the semantics. For example, if I'm exposing a salon's schedule as a resource, perhaps when a booking is cancelled it is thrown away (or otherwise made inaccessible). But in your case, you would still want make the cancelled booking available to REST clients, so PUT would be more suitable for you.