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.
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 am just wondering if 404/400 Responses in a node express app is consider an error and if it will be caught by the error handling middle ware?
I had a hard time finding this in the documentation
In HTTP/1.1, a response code of 400 or higher is considered an error.
However, Express error handling only deals with programming errors, not HTTP errors. If your app detects an error condition and sends back a 400 or 404 response, Express doesn't care (i.e. it won't call the error handler).
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.
Is there any way to get detail exception & Stack trace from deployed Web Api?
Even if I deployed in Debug mode, do I get detail error traces?
I got bellow message from server API
"message": "Processing of the HTTP request resulted in an exception.
Please see the HTTP response returned by the 'Response' property of
this exception for details."
This happened only in server, same code running perfectly in local machine.
Did you check the content-type for the request that you are performing?
Sometimes this error comes because you don't specify this value, e.g. "application/json" in the headers of the request.
If your scenario is to have a central place to log any exceptions that happen when requests are being processed, then I would suggest to take a look at 5.1 version of Web API (released couple of days back), specifically the Global Error Handling feature.
http://www.asp.net/web-api/overview/releases/whats-new-in-aspnet-web-api-21#global-error
If you go to the above page,you should notice ExceptionLoggerContext which gives you details of the exception.
About Web API versions 5.0 and before:
In these versions there was no really a central place for catching exceptions. ExceptionFilterAttributes caught exceptions for only certain areas of Web API.