When building REST web services in .NET, what is the most "RESTful" way of mapping System.ArgumentNullException and System.ArgumentException to HTTP status codes? My first guess would be to use HTTP 400/Bad Request with an appropriate description.What is the recommended best practice when mapping exceptions to HTTP status codes?
In general, the 4xx status codes tell the client that the request failed but may succeed if the request i smodified. The 5xx codes inform the client about problems that where the client has no influence.
So the first distinction you have to make is between 4xx and 5xx codes, i.e. tell the client if it should retry or not.
HTTP 400 "Bad Request" should be used if the request was indeed syntactically malformed, incomplete, contradicting or otherwise basically wrong.
Additionaly it may be a valid default status in the 4xx range, if no other status seems appropriate and you believe the client needs only to modify the request to succeed.
It depends on the context. E.g. an ArgumentNullException could stem from a violated precondition or be an internal server error.
Regards,
tamberg
Related
I have gone through all status code of Web API and couldn't find right fit for below scenario.
My API is dependent on third party service and the results from service are invalid, in such case what kind of status code I should return?
400 - Means bad request, and there isn't anything wrong with request.
500 - Raising 500 doesn't make sense as it can be handled and want to give appropriate message in response.
200 - As response is not successful, I can't give any 2XX status code.
Thanks for suggestions in advance.
My first thought is:
502 Bad Gateway
The server was acting as a gateway or proxy and received an invalid response from the upstream server.
Wikipedia
I have some logic in the web server to find out if the user is trying to do a DoS attack. But what's the correct HTTP response code to return for that? Also what's a good error message I can put in HTTP body to tell the user politely that he's got into the DoS attack path?
But what's the correct HTTP response code to return for that?
RFC 6585 suggests 429 Too Many Requests
The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting").
If the attack has compromised your ability to handle legitimate requests, then to those you might respond with 503 Service Unavailable.
Note the change in semantics - the person sending the bad requests gets a status out of the 4NN Client Error class, while those not at fault get a status from the 5NN Internal Service Error class.
what's a good error message I can put in HTTP body to tell the user politely that he's got into the DoS attack path?
Please stop that?
So i'm designing a Restful Api that makes calls to other web services aggregates the result and return back to the client. If connection of any of the other web services fails for any reason, what is the best thing to return?
Right now am returning an 500 - Internal Server error to the client but I would like to return more details to the client on what made the request to fail. Would it be redundant to return a 500 http response code with a response body containing a message detailing where the error actually occurred or to just return a 503 - Service Unavailable http response code?
Your response code should depend on what you can do with the request. If clients can expect in this case to receive partial information and a message indicating what remote data feeds are unavailable, then send back a 200. I would not include HTTP codes or failing URIs in that response, just the names of the providers that are unavailable, and possibly a reason why. If you do, you may find yourself broken when you need to add non-URI-based providers. If you must, then make sure to include a "type" and require clients to use it. This will partially future-proof you, but expect that many clients will ignore the type and break if you add new types later.
If clients can't do anything with partial data, then you should return a 503 because your service is unavailable. It happens to be unavailable because a remote server it relies on is down. That's no different than returning a 503 because your own database is down. Your API can't return something because something it needs isn't available right now, but will be again later. You should include in the body of the response the reason for the outage, and may include a Retry-After header if you have any idea as to when the remote server might be available again.
A 404 is not appropriate because it means that the resource being requested does not exist - an error by the client. The resource does exist, it just can't be returned right now, because your server can't build it.
A 409 is not appropriate because there is no conflict that the user can resolve.
A 206 is not appropriate because it is to be used when the request includes a Range header, and there's no indication these requests do.
Since your aggregation is basically not finding what it seeks, perhaps HTTP 404 Not Found is appropriate.
If not all remote calls fail, so there at least are some relevant results, you could return HTTP 200 OK with an additional status informing that some remote sources currently are unavailable.
I would not return HTTP 503, as this code implies that your service is temporarily unavailable - and you therefore suggest the client retries later. HTTP 503 is typically returned when a server is restarting and is not quite ready to serve requests.
I am working in an API . I want to throw detailed error messages to the user. Now i am in a situation to decide what kind of error code should be sent or how to explain user if any error occurs in the application internally. For example if database connection fails , what kind of http status code i want to send to the user ?
Can anyone help ?
An HTTP status code generally refers to the status of the HTTP request itself, not the status of the application handling the request. Therefore, most server-side errors are covered by 500 Internal Server Error. Any additional info about the error should be described in the response body. For APIs, the response body will often be JSON or XML, so you can use those formats for your errors. Something like this:
HTTP/1.1 500 Internal Server Error
[headers]
{"status":"error", "message":"The request failed due to database connectivity."}
There are, however, two cases I can think of when you might want another status code. If the user has requested an API method that is not implemented, you might want a 501 Not Implemented, and when there is a temporary service outage, you can use 503 Service Unavailable.
More info about server-side status codes here.
I'm getting a 4XX client error, I have never come across these before (maybe naively).
This is frustrating me, because my page seems to be working fine but when scanning it for SEO purposes I am getting two 4xx client error in
Put simply, what are they?
The HTTP 1.1 RFC explains and lists all of the 4xx errors.
"The 4xx class of status code is intended for cases in which the client seems to have erred."