Detail HTTP status codes to use for various error conditions #354
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Note: the original name for 422 was "Unprocessable Entity", but it's more commonly know as "Unprocessable Content" these days. The text itself is unimportant, so unimportant HTTP2+ doesn't even include it in the response any more IIRC. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We should embrace HTTP semantics as much as possible. Previously I over-specified the status codes to make it seem like 400 should be used for everything when actually you should use the appropriate status code for the situation. I've attempted to address this by being much more explicit, and have split the previous examples into 400 (syntactically invalid request) and 422 (syntactically valid request, but semantically unprocessable) whilst also putting recommendations for various other HTTP status codes you should consider using inspired by various situations you're likely to see as a GraphQL server. I've tried to define them mostly in a sort of "chronological" order of the way that you would process a request.