4 ms·

Do both together. Use GET/POST/PATCH/DELETE for the simple CRUD on the resource. Then, put your actions under POST /resource/{id}/actions/{action}, e.g. `/rep

Do both together. Use GET/POST/PATCH/DELETE for the simple CRUD on the resource. Then, put your actions under POST /resource/{id}/actions/{action}, e.g. `/repositories/1/actions/archive`, `/users/1/actions/ban`, `/customers/1/actions/credit-score-with-bank-of-xyz`, etc

always_good 9y ago
I don't see why you'd want the /actions/ segment at all. That's like using a /resources/ prefix at the start of every endpoint.
urethrafranklin 9y ago
I find the "/actions" slug a bit goofy and unnecessary. Why not just put it at e.g. "/repositories/1/archive"? Additionally, why not maintain restful semantics by using PUT (or more likely, PATCH) instead of POST (which implies creating a new resource)? And "/customers/1/actions/credit-score-with-bank-of-xyz" sounds a lot like a GET request.
- denisw 9y ago
  I agree about /actions, it is unnecessary. However, for these kinds of "action resources", POST is definitely the best-matching request method. It does not mean "create a resource" (although this is one case it is often used for), but "process this request in your custom resource-specific way". The HTTP RFC formulates it like this [1]: > The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. Given that what an action resource does is, by definition, resource-specific, POST fits perfectly. [1]: https://tools.ietf.org/html/rfc7231#section-4.3.3 https://tools.ietf.org/html/rfc7231#section-4.3.3
- HatchedLake721 9y ago
  Because there could be related resources, e.g. "/repositories/1/users", or "/users/1/comments". I agree it's not necessary, but having /actions just makes it more clear. For example: "/repositories/1/bans" shows me all bans "/repositories/1/ban" ban action I know it's a bad example, but you could end up with other similar related resource and action names that could increase chances of silly mistakes.

always_good 9y ago

I don't see why you'd want the /actions/ segment at all. That's like using a /resources/ prefix at the start of every endpoint.

urethrafranklin 9y ago

I find the "/actions" slug a bit goofy and unnecessary. Why not just put it at e.g. "/repositories/1/archive"? Additionally, why not maintain restful semantics by using PUT (or more likely, PATCH) instead of POST (which implies creating a new resource)? And "/customers/1/actions/credit-score-with-bank-of-xyz" sounds a lot like a GET request.

denisw 9y ago
I agree about /actions, it is unnecessary. However, for these kinds of "action resources", POST is definitely the best-matching request method. It does not mean "create a resource" (although this is one case it is often used for), but "process this request in your custom resource-specific way". The HTTP RFC formulates it like this [1]: > The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. Given that what an action resource does is, by definition, resource-specific, POST fits perfectly. [1]: https://tools.ietf.org/html/rfc7231#section-4.3.3 https://tools.ietf.org/html/rfc7231#section-4.3.3
HatchedLake721 9y ago
Because there could be related resources, e.g. "/repositories/1/users", or "/users/1/comments". I agree it's not necessary, but having /actions just makes it more clear. For example: "/repositories/1/bans" shows me all bans "/repositories/1/ban" ban action I know it's a bad example, but you could end up with other similar related resource and action names that could increase chances of silly mistakes.