In my API Gateway, I use 422 status code for errors that are not related to the standard HTTP status codes (400, 403, 404 ...)
I linked my API Gateway stage to a CloudFront distribution.
When I invoke my API with the default URL (https://#####.execute-api.us-east-1.amazonaws.com/stage) I always get the 422 error as "422 Unprocessable Entity (WebDAV) (RFC 4918)"
But when I invoke it throw the CloudFront distribution, sometimes I get "422 Unprocessable Entity (WebDAV) (RFC 4918)" for POST requests, and sometimes I get "422 Unknown" for GET requests. This broke some tests that check for the HTTP status name.
What is the expected behavior for this HTTP status code?
Related
What HTTP response code should be returned when a POST request was not successful and a request body was correctly formatted?
For successful POST request i am using 201 - Created, but there is no equivalent not created code.
I am thinking either 400 - bad request but that would actually point user that a request is poorly formatted or 304 - not modified.
What HTTP response code should be returned when a POST request was not successful and a request body was correctly formatted?
If you mean the syntax of the request payload is valid but it cannot be processed due to invalid data, you can use 422:
11.2. 422 Unprocessable Entity
The 422 (Unprocessable Entity) status code means the server
understands the content type of the request entity (hence a
415 (Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct (thus a 400 (Bad Request)
status code is inappropriate) but was unable to process the contained
instructions. For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous, XML instructions.
Remember to provide a good description in the response payload explaining what's wrong with the payload. Refer to the RFC 7807 for details on how to report problems in HTTP APIs.
Updates (according to the comments)
The reason why a POST request would fail is more of a business logic error, for example "account balance too low to withdraw 5.00 USD".
For the situation described in your comment, 403 or 409 would be a better fit.
6.5.3. 403 Forbidden
The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to
make public why the request has been forbidden can describe that
reason in the response payload (if any). [...]
6.5.8. 409 Conflict
The 409 (Conflict) status code indicates that the request could not
be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server
SHOULD generate a payload that includes enough information for a user
to recognize the source of the conflict. [...]
I am building an API and I am returning this kind of status codes for each method (e.g., "register_user"):
200 (OK) when the user has been registered successfully
403 (forbidden) when there are missing parameters in the request
409 (conflict) when a user was already registered
In addition to the status code, I return a "message" field explaining what happened. Do you consider returning these codes in this example a good practice? Or should I return 200 in all of them but an error in the "message" field?
The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to
make public why the request has been forbidden can describe that
reason in the response payload (if any).
-- RFC 7231, 6.5.3
That doesn't sound like what you've got at all. The other two are reasonable. Missing parameters are typically handled with a 400 response code.
I have an API endpoint and the request should have a cookie (not authentication). What would be the correct HTTP status code to return if it isn't present?
I would assume a 400 Bad Request would be the best.
No much details are provided in your question, but I guess 400 (Bad Request) is a good option:
6.5.1. 400 Bad Request
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
However, depending on your requirements, you also could consider the 422 (Unprocessable Entity) status code, defined in the WebDAV specification, which is just an extension of the HTTP protocol:
11.2. 422 Unprocessable Entity
The 422 (Unprocessable Entity) status code means the server
understands the content type of the request entity (hence a
415 (Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct (thus a 400 (Bad Request)
status code is inappropriate) but was unable to process the contained
instructions. For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous, XML instructions.
Just remember providing a good description in the response payload explaining what's missing in the request.
I would consider a 403 forbidden status code for this situation - where everything else is fine but the request is missing a cookie. To copy its details from the linked reference:
The server understood the request but refuses to authorize it.
If authentication credentials were provided in the request, the server considers them insufficient to grant access
Status 401 unauthorized is for when the request lacks authentication credentials. But 401 also requires the response to contain a WWW-Authenticate header field. Based on the question, the request should have a cookie but doesn't, and it isn't a matter of authentication.
Status 400 is when the client request was erroneous, which might be a bit misleading for the scenario the OP describes.
Status 422 might be appropriate, but I think, a bit too generic since it means something on the lines of everything was okay, but the server is unable to process the request.
RFC 2616 says 502 means: "The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request."
What exactly counts as an invalid response? Does this include something like a 500 from the upstream server?
Imagine that you have implemented and API that aggregates responses from a couple of third party servers. E.g. you have an application that if asked for info about lol#lol.com user will return all the public data about this user from FB, TW and G+.
More or less your API acts as a proxy server. Now if one of these requests fails you have a choice what will be returned to the client. If you want to be explicit about how your application works you can return 502 Bad Gateway along with message: Sorry, request to FB failed for whatever reason and that's all. But you can also hide the implementation details and return a e.g. 409 Conflict response along with details: Have no info about the user's FB activity.
In this particular example 207 Multi Status would be also very useful.
I have an api endpoint that returns a Voucher object.
The voucher is retrieved from a third party.
There are some conditions, for example an expired date, that we check for / validate on.
So, if a client application requests /voucher/1234 voucher with id 1234 is retrieved from the third party.
If the expired date is < now, we need to return an error.
I want to return standard HTTP errors.
Which would be the most suitable?
I initially thought a 412 would be, but now I'm not sure.
HTTP 412 is used when the server doesn't meet one of the preconditions(If-Match, If-Modified-Since, etc) supplied in the request header.
The very generic way would be to return HTTP 400 + specific error message on invalid fields.
However more and more populer APIs are starting to use HTTP extensions to be more granular with the error feedback to the client. Twitter and GitHub use HTTP 422 Unprocessable Entity as defined in the WebDAV HTTP extension. HTTP 422 says that :
The 422 (Unprocessable Entity) status code means the server
understands the content type of the request entity (hence a
415(Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct (thus a 400 (Bad Request)
status code is inappropriate) but was unable to process the contained
instructions. For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous XML instructions.
Your server understands what the user wants to do and understands what the data contains, it just won't let you do that. So, Http 422 looks good for you.