Say we have an Invitation model. Invitations can be fully CRUDed while they are in draft, but once they are sent, editing should be impossible.
To deny edits, we could start with changes to the UI - perhaps remove links/buttons leading to edit, but this does not preclude users navigating to edit form directly.
Perhaps we can modify the edit form also, make everything disabled, remove submit button.
This should be safe enough for internal systems, but a system facing public internet should probably also have some safety on the back-end - at least in update action and maybe even in the model validation or even readonly level.
This leads us to what HTTP status to respond with if an update request for an already sent Invitation comes in.
Possibilities:
- bad_request: 400, # tells users they could change request somehow for it to succeed
- unauthorized: 401, # tells user auth credentials were missing and they need to log in
- forbidden: 403, # tells user they are logged in, but have no permissions to update
- precondition_failed: 412, # deals with specific headers
- unprocessable_entity: 422, # tells user request was understood, but cannot be carried out for some reason
The split is between 400 and 422, and 422 wins because it more clearly communicates that request was OK, and that there is nothing the user can change to make the request succeed.
See also SO thread of 400 VS 422
Top comments (0)