- You are referring to an entity, not to a collection.
- The entity you are supplying is complete (the entire entity).
- Idempotent
- Could be used for partial updates but need to create a new resource for every field. PUT /users/123/email, /users/123/address
- Partial updates
- Not idempotent
- Create new entity
- Not idempotent
- POST is usually for new resource creation. It can also be used as a catch-all verb, such as a utility API request. (Utility API is different from regular resource operation. Example: validating a marketing promotion code.)
- 409 for when a conflict of data exists.
- 400 when input is malformed
- 401 for when an access token isn’t provided, or is invalid.
- 422 input is understood correctly but this request is semantically invalid. (Email already activated ?)
- 403 for when an access token is valid, but requires more privileges.
- 201 if a new resource was created in response to this request.
- 202 if the request was accepted, but will be processed asynchronously.
- 204 if you have no useful response entity (DELETE responses)
- Note that these codes are intended for the API service layer, not for the business logic layer. For example, when the search result of /search?q=xyz is empty, the server should return a 200 rather than 404, because the “/search resource” exists and the request is fulfilled successfully.
- Non-enveloped array is exploitable. OWASP recommends to always return JSON with an object on the outside.
- Use singular for singleton resource (i.e. only one instance is possible for the client). For example, the user in GET /user/subscriptions of GitHub watching API is singular because it refers to the current authenticated user.
- Utility API is different from resource API; any reasonable endpoint choice would be fine. For example: /search?q={keywords}.
- 401 vs. 403: 401 means the client has not been authenticated. (The use of “Unauthorized” by the HTTP spec is somewhat misleading.) 403 means the current client (usually authenticated) or all clients are not allowed for the request.
- http://restcookbook.com/
- http://www.restapitutorial.com/
- http://stackoverflow.com/questions/2443324/best-practice-for-partial-updates-in-a-restful-service
- http://stackoverflow.com/questions/28459418/rest-api-put-vs-patch-with-real-life-examples
- https://medium.com/studioarmix/learn-restful-api-design-ideals-c5ec915a430f
- https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm