3 ms·
Look, I'm not a REST cheerleader by any stretch of the imagination but in REST terms the OP just doesn't know his ass from his elbow here. Consider: > POST /or
by cletus 15y ago
Look, I'm not a REST cheerleader by any stretch of the imagination but in REST terms the OP just doesn't know his ass from his elbow here. Consider:
> POST /orders/42/pay
> POST /orders/42/ship
You don't put verbs in your URLs. This is really REST 101. I highly recommend Nobody understands REST or HTTP [1]. The above is exactly why you don't put verbs in URLs. Consider instead:
POST /payment { orderId=42, etc }
POST /shipment { orderId=42, etc }
is a much sounder RESTful API design.
And in case anyone feels the need to suggest SOAP, I highly recommend the satiricial (but disturbingly accurate) The S stands for Simple [2].
[1]: http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http http://blog.steveklabnik.com/posts/2011-07-03-nobody-underst...
[2]: http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/ http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...
- jeffmess 15y agoPlacing verbs in your Resftul apis resources is wrong, but it just feels so right....
- bluesnowmonkey 15y agoMaybe you just skimmed the article, or he's changed it since, but he doesn't say that verbs in URLs was RESTful. He said it was better than RESTful, and I'm inclined to agree with him. Having tried my hand at designing REST APIs for typical business systems a few times, I've noticed that state machines and transactions are everywhere. Making every resource a noun with the four basic REST verbs leads to a complex and extremely chatty design, whereas slipping a few extra verbs in here and there makes the API simpler, easier to understand, and more efficient.