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.
Related
we have a application that makes a web service call to Mule ESB and the log shows mostly 500 error code during peak hours and 200 success code during off peak hours. I am not part of the Mule team, but when I talked with them they indicate that this may not be a problem on their side, they are saying nothing is received on their ends.
Now my question is if our application logs show 500 error code, won't that indicate the request has made it to the Mule ESB but was not able to process it or still possible to get 500 error code if the request is lost somewhere due to networking / router issues or similar to that?
The question is totally generic and doesn't provide any insight on the implementation. Then his answer applies to any HTTP response from any implementation and technology, be it Mule, Java Python, etc.
The answer depends on if the server is using the 500 response correctly. If they just answer 500 because it doesn't handle errors correctly then there is nothing you can imply from that.
If 500 is used correctly it is an internal error. If the issue is that they don't receive a proper response from another backend it be argued if there is not a better response code for that like 502 or 504. In any case is that team that manages the app who should troubleshoot the error.
What you can buy sure is that the request reached the application because it responded with an HTTP response.
I'm developing an application with authentication, and i need to provide a appropriate status code if there is any error when registering an user, for example a database-related error.
I've been researching but i haven't found an appropriate status code.
The purpose of all HTTP errors is to communicate the operation failed. To pick the right HTTP error, you need to know why it failed.
"database-related error" sounds like a server-side bug or problem, so this is likely just a 500.
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?
I am creating an object in parse (using back4app parse server for this).
I get the following error when I run the choreo in temboo.
A HTTP Error has occurred: The remote server responded with a status
code of 401. Typically this indicates that an authorization error
occurred while attempting to access the remote resource. The data
returned from the remote server was: {"error":"unauthorized"} . The
error occurred in the HTTPSend (Parse) step.
That 401 error might indicate that the Id or Keys are not correct. Maybe it could be a good idea to double check them.
Also, what is the host and path for the API Request that you're doing with Temboo (I'm not acquainted with it)? If you're not using the correct ones it might cause problems too.
Make sure you're reaching something like this:
https://parseapi.back4app.com/classes/Your_Class_Name
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.