4 ms·

I can see why this would be the case given the constrains imposed by the the REST architecture, but I don't really see what benefits this has over having some s

I can see why this would be the case given the constrains imposed by the the REST architecture, but I don't really see what benefits this has over having some sort of "cancel" action to be performed on the booking resource. Sidenote: Is it "better" to pass booking_id = number, or booking = booking resource URL. Why?

icebraining 15y ago
>I can see why this would be the case given the constrains imposed by the the REST architecture, but I don't really see what benefits this has over having some sort of "cancel" action to be performed on the booking resource. The problem isn't so much REST, but HTTP: using a custom method could have the potential of creating havoc with proxies and such. > Sidenote: Is it "better" to pass booking_id = number, or booking = booking resource URL. Why? I think the ID should be the URL. It decouples the client from the internal IDs, which is not only DRYer (since otherwise you'd effectively have two IDs) as it can help if you need to change the internal ID format.