I have seen people using the HTTP code 500 as a generic error code for all kind of error cases (server errors, http errors, code exceptions, expected record not found in DB, time-out exceptions etc). However I have also read and heard that this code 500 should only be used in case of errors originating from the application server (JBoss in my case), and NOT application itself i.e. not for code-exceptions or invalid passwords or DB-record-not-found cases. So, when should we return HTTP Status Code 500 from a REST service method?
As described in the HTTP spec:
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. A user agent SHOULD display any included representation to the user. These response codes are applicable to any request method.
Original: https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.6
Note that from the protocol point of view, it doesn't matter whether it's the application server or something running inside the application server.
Related
Part of my rest API calls and external service. This service could, of course, fail for any reason. What's the suggested code that my API should return to the client?
500 Internal Server Error seems inappropriate: why would I return 500 for something that is not "my fault"?
In this specific case:
the user try to place an order
If order is invalid, 400 would be returned
If order is valid, the order is sent to the external API (which may fail)
The appropriate status code should be returned to the client
From this post (HTTP status code for temporarily unavailable pages) it seems like in this situation 503 Service Unavailable is the most appropriate which I myself would also do in this situation.
Why is error 410 considered a user error (4xx) and not a redirect (3xx) or a server error (5xx)?
I request a payload from a server, and the server returns a link. I copy the link and the link gives 410? It isn't my fault to verify the link actually exists on their server. But at the same time, from the server's point of view the error originated from me, as I accessed something that doesn't exist, similar to 404 where I access something that was never there.
Can anyone help me understand the decision behind this?
Code 410
"410 Gone" client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent.
If you don't know whether this condition is temporary or permanent, a 404 status code should be used instead.
Why is error 410 a user error and not a server error?
It's not a "user" error, it's a client error; but yeah, that's a lousy label. The labels reflect the client-server architectural constraint, but it might be better to use labels that point more directly at the contents of the request, rather than the client (or the user).
In practice, it's a client error for the same reason that 404 is a client error; it is specifically calling attention to the target resource of the HTTP request.
In the context of the web, it does make some (imperfect) sense - the client followed a broken link (which could be a consequence of the server's current representations, but might also come from following links in stale representations, following stale bookmarks, a spelling error in a representation provided by a different server, etc).
It's not a question of fault, it just means that the request should not be considered to ever work in the future (it shouldn't be retried). Whereas a server error (like a 5xx error) could be retried periodically and should eventually work sometime in the future since the request itself is considered valid.
I wrote a Node service that takes parameters from a client and puts them into a SOAP request to another (3rd party) service. Lately, when a request is made to my service, the initial response is a 502 Bad Gateway error with a generic HTML block titled "Server Error" (see image). When I submit the same request a second time, the 3rd party responds with a 500 Internal Server error and a message indicating that a request has already been issued for that transaction.
Obviously the initial request made it to the 3rd party somehow, but they say that the 502 error isn't theirs and isn't logged in their system as ever having occurred.
What I'm trying to find out is if the error is somehow coming from my service because of Docker or Azure (or something else I'm not thinking of). The error is so generic that research hasn't yielded anything useful on it. Has anyone encountered this or know what it is?
It turns out that this was an error being thrown by Azure (or so we think) as the result of some faulty error-handling. Part of the response was being parsed incorrectly, which caused the app to stall. It still doesn't explain how the data still got to the other side while this was happening (or why it hit the catch block at all when there was no error in the processing), but if you see a server error returned with this HTML block, check your error-handling code and investigate Azure!
I am performing a POST to a resource URI. But the success of this operation depends on the responsiveness or accessibility of another related object. If that object is not responsive or inaccessible, the operation needs to return failure. What HTTP code should I choose in this case?
I am currently brainstorming on the following codes, but could not arrive at the right one:
404 NOT FOUND - This represents "not found" for the resource URI, and not a related inaccessible entity.
412 PRECONDITION FAILED - Applicable only for conditional requests with one or more header fields indicating a precondition - I dont need to provide any.
I am not able to find or zero onto a specific HTTP code.
https://greenbytes.de/tech/webdav/rfc7231.html#status.409:
"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."
Lets check the candidates:
404: always an option but as the same request will sometimes fail or success this will create a flickering behavior which is not what a client would expect when getting 404.
412: RFC 2616 says: "The precondition given in one or more of the request-header fields" - this is not the reason for the failure.
417: similar to 412: "The expectation given in an Expect request-header field could not be met by this server"
503: "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server."
Nothing seems to be perfect but I would choose 503 as it represents the temporary problem best and guides the client to do a retry.
Picking the right status code is always tricky. If you return a status code like 404 for example, debugging can become derailed because someone may not be sure if it's because the URL actually doesn't exist or if it's because of some other reason internally.
Usually the caller only needs to know a few things:
Did the endpoint exist? If not, 404 NOT FOUND
Was my request properly formed and did it pass validation? If not, 400 BAD REQUEST
Was my request denied because of improper authentication? If not, 401 or 403 depending on the context (there is a subtle difference)
Did my request fail because of something out of my control? If so, 500 INTERNAL ERROR
Typically I try to separate the response from the service's logic. If you want to be more specific as to exactly what happened (in your example a dependency is not responsive), returning a bit of JSON that describes in more detail what the problem was is would be a more appropriate place for that as opposed to using the http status code to describe a specific error on the service side.
So in your case, I think 500 is the most appropriate. The caller just knows that something went wrong and there's nothing it can do about it, and it can handle that condition however it needs to. If the caller needs to know more about what happened, use a JSON response to convey that.
List of HTTP status codes
1xx Informational
2xx Success
3xx Redirection
4xx Client Error
5xx Server Error
Refer wiki :
103 Checkpoint
Used in the resumable requests proposal to resume aborted PUT or POST requests.
420 Method Failure (Spring Framework)
A deprecated response used by the Spring Framework when a method has failed.
420 Enhance Your Calm (Twitter)
Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.
450 Blocked by Windows Parental Controls (Microsoft)
A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.
498 Invalid Token (Esri)
Returned by ArcGIS for Server. A code of 498 indicates an expired or otherwise invalid token.
499 Token Required (Esri)
Returned by ArcGIS for Server. A code of 499 indicates that a token is required but was not submitted.
499 Request has been forbidden by antivirus
Produced by some programs such as Wget when a malicious site is intercepted.
509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)
The server has exceeded the bandwidth specified by the server administrator; > this is often used by shared hosting providers to limit the bandwidth of customers.
530 Site is frozen
Used by the Pantheon web platform to indicate a site that has been frozen due to inactivity.
My payment endpoint which accepts a POST should deny requests when the user does not have any payment methods configured. What is the correct HTTP status code in this case?
What is the correct HTTP status code to be raised when the system itself cannot reach the state asked for by the request and another request (creating a payment method) must be completed first?
I looked at 428 Precondition Required, but that seems to have more to do with the headers than the state of the system.
I would go simply with 400 Bad Request. If you need more specific instructions or hints in the response, you can return a body, which will indicate the exact nature of the error.
You don't need to assign a specific HTTP error code to all your internal business-related error cases. Indeed this is probably not possible anyway.
The specification on 400: https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1
Relevant quotes from there:
indicates that the server cannot or will not process the request due to something that is perceived to be a client error
And about the 4xx codes in general:
the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition
Did you look into error 424 Failed_Dependency? I think this could bethe one you want.
See
http://www.restpatterns.org/HTTP_Status_Codes/424_-_Failed_Dependency