4 ms·
> POST /orders/42/payment > POST /orders/42/shipment Fixed?
by 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