7 ms·
> POST /orders/42/pay > POST /orders/42/ship But "pay" and "ship" are actions, not objects, so it doesn't make a lot of sense for them to be represented as UR
by RyanMcGreal 15y ago
> POST /orders/42/pay
> POST /orders/42/ship
But "pay" and "ship" are actions, not objects, so it doesn't make a lot of sense for them to be represented as URLs.
- rch 15y agoYou hit the nail on the head there. If the author posted a new payment (using whatever metaphor), then a handler could initiate a set of actions in the course of processing <metaphor>. Maybe this is a real debate in some circles, but I cannot fathom mapping HTTP verbs directly to SQL statements.
- kevinpfab 15y agoExactly. Having these endpoints instantly turns your API into an RPC-API. This is the start of a snowball of complexity introduced for your consumers.
- bad_user 15y agoI understand why that isn't RESTfull, but why is it more complex? "customers" are used to thinking in terms of actions. You hit this little button here for payment, you hit this other little button here for shipment. And for developers, these are like methods containing business logic belonging to an object. So where's the problem?
- pfraze 15y agoHTTP requests are actions -- that's why they have verbs. URIs should be concepts those verbs act upon. GET /orders/42/pay is a verb on a verb. Maybe not complex, but definitely confusing.
- T-hawk 15y agoPAY /orders/42 That's the most natural mapping, the verb PAY on the object of order 42. Maybe HTTP needs arbitrary verbs instead of a limited predefined set? We'd have to get firewalls and proxies and such out of the habit of processing a request depending on its verb.
- lloeki 15y agoThe point of having limited and well defined HTTP verbs means that you know what to expect. e.g GET has no effect on the resource, while PUT is idempotent, and POST is neither. This precise set of definitions, along with the remainder of REST principles mean that friction is greatly reduced when building/consuming APIs.
- pfraze 15y agoThere's actually nothing stopping you from using your own verbs, actually; it's allowed. Lloeki gives a good reason not to, though: I don't know how PAY will be handled without consulting documentation.
- scoot 15y agoIsn't how any of the supported HTTP verbs is handled dependant on the API? <consults documentation...>
- pfraze 15y agoYeah, but not totally. For instance, you can always guess what a GET does. There are properties of the established verbs that you can expect.
- bluesnowmonkey 15y agoThe HTTP spec is -- it only specifies certain verbs. An implementation need not (and often doesn't) support others.
- strictfp 15y agoIt's not a problem, but you don't get all the benefits of HTTP if you don't respect REST. This since HTTP is built around the idea of REST. To me it seems logical to embrace the ideas of the tool you are using. If you are not utilizing the power of HTTP, why not just use a pure RPC protocol? I think that we eventually have to open up for more protocols if the web continues to develop into a generic dev platform. In a sense we are already heading in that direction with WebSockets. But since HTTP has been and continues to be such a success, I think that we can atleast try to promote it.
- kevinpfab 15y agoThis configuration can still be RESTful as long as you POST to those endpoints. The complexity I was referring to is the snowball effect of adding different actions. If you use hypertext in the resources to specify the places the client can go, the complexity is severely reduced. However, properly enabling discovery is where most "Rest" APIs fail.
- dalore 15y ago> POST /orders/42/payment > POST /orders/42/shipment Fixed?
- pfraze 15y agoYeah.
- Roboprog 15y agoPretty close. If you really want to make the process "safe" (idempotent, to avoid double posted payments), you might actually have to do something more complicated such as: GET /order/42/payment/new (returns "3", for example) PUT /order/42/payment/3 (supplying content for payment info and amount) Re-issuing the "PUT" (in case confirmation was lost? user double clicked "submit"?) would simply resend the same value, thus, an "idempotent" action. Viewing this particular payment is simply: GET /order/42/payment/3 Without the "3", who knows which payment you would get? (unless you got back the list of all payments on the order so far) I'm not sure if this an argument for or against REST, but I'd sure hate to see a SOAP example typed into a "comment box" in a discussion forum :-)
- pfraze 15y agoGood point. I wonder, though-- could you make /order/42/payment the only payment resource related to /order/42, so the ID isn't needed? (PUT /order/42/payment) If the payment doesn't cover the bill, you could have the PUT respond with a link to /order/42/payment/remaining/1, then (if needed) continue with /remaining/2, and so on. That would avoid the danger of a gap between your id GET and the payment PUT.
- pbreit 15y agoShouldn't it be: POST /payment order=42 Or: POST(or PUT) /order/42 status=shipped
- silon4 15y agoPOST /orders/42?pay=1 POST was always about actions, not just resources.
- RyanMcGreal 15y agoAn HTTP request has two parts: a resource (URL) and a method. Expressing your method in the resource rather than the, um, method muddles the two.