When constructing an API response, which method is better for (manually) returning the status code to indicate the validity of the request:
1 - Embed a response code within the JSON response
{
'status_code' => 200,
'status_message' => 'OK',
'data' => { ... }
}
2 - Or is it better to modify the HTTP Headers Status field?
Request URL:http://somesite.com
Request Method:GET
Status Code: 200 (EDITING THIS ONE)
I would think that the HTTP Statuses should only be regarding connection errors and file retrieval errors that occur at the server level rather than altering this to address application level errors.
Any good articles and resources to read would be very appreciated as well.
I have found the best way to present errors in a REST Request is to change the HTTP Status Code to the proper error, and embed the error in the response.
If you are using JSON, it might look like this, with the status code set to 500 for this example:
{"error" : "An error has occurred while trying to read from the database."}
This is the same method that Microsoft CRM uses to report errors, and it has proved to be a good method; RESTFul applications will not fail to parse the response if they are expecting JSON (or XML, if you are using that).
This question addresses the same issue (perhaps from a slightly different perspective).
I think that, in general, if a request to a resource in your application results in an error condition, that fact should be reflected in the HTTP headers. You can use the application response to provide more detailed information.
Update: Here is an interesting mapping of application errors to status codes (used by Azure).
Related
I have written a REST API in nodejs.
I want to send HTTP status codes on various events.
For example when data is returned I send HTTP code 200.
What is the status code to return when the input data is missing?
This isn't specific to nodejs. HTTP status codes are general -- you can read about them on wikipedia:
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
I think you want client error code 400, which means Bad Request.
Perhaps you should return 404, not found. As mentioned in previous answer, HTTP status codes are general.
A tip: try getting grip on HTTP before starting off web development.
I'm new to the .NET web api. But I can't figure out what the best practice should be when returning status codes. I've followed the tutorial on creating a web api that supports crud operations to get a good idea on how it all works.
I have a spec where the response to every request returns a status code along with other data, I can change the spec if need be but I can't work out if it's good to return a status code and also return all the data requested or to just return the data on it's own.
For example if I made a request to GetAllCarManufacturers without being authenticated I'd return a custom statusCode of 1 (Indicating not authenticated), and message "User is not authenticated.". But if I was authenticated I'd like to send back a statusCode of 0 (indicating success) and all the car manufacturers. This seems to go against the way the tutorial is organised as only the car manufacturers are sent back without any additional data. Which leads me to believe passing around a statusCode isn't the correct thing to do.
I've seen in the example crud demo that HttpResponseExceptions are thrown which sets the HttpStatusCode to a certain value (see code below). Should I be using that instead of returning my own status code? But then my concern is it doesn't have enough different status codes that will match my custom scenarios.
// Setting the HTTPStatusCode example.
throw new HttpResponseException(HttpStatusCode.NotFound);
.NET Web API sets up a convention for HTTP calls to a server that supports a REST interface. So, if you follow the convention, you should return HTTP Status Codes as a way of indicating what happened to the request when the server processed it.
HTTP Status Codes are part of the HTTP spec and can be found here.
There are many benefits to using HTTP Status Codes. One is that the HTTP Status Code is a header, so the client doesn't have to look into the content of the response in order to find out what happened.
So, returning a custom status code (of say 0 or 1) is not very useful to HTTP clients if they expect a RESTful experience from your interface.
How to add the unhandled exceptions accross the applications in response body in WEB API. If there is no exceptions a success message needs to be sent to the response body for all the responses....Need help on achieving this.
You need two things. For handling the exceptions, you need to set the IncludeDetailErrorPolicy in the HttpConfiguration object,
You can configure the error policy preferences as part of the configuration object (HttpConfiguration) in the IncludeErrorDetailPolicy property. This is just an enum that instructs Web API about how to deal with exceptions.
The possible values for this enum are,
Default: It’s uses the customErrors configuration settings if you are using ASP.NET as host or LocalOnly for self-host.
LocalOnly: Only includes error details for local requests
Always: Always includes error details
Never: Never includes error details
When an exception happens, Web API will check the value on this setting for including details about the exception in the response message or not. For example, if Always is enabled, Web API will serialize the exception details as part of the message that you get as response.
The success message does not make much sense as you already have the response status code. A status code equals to OK means that everything went ok. If you still want to add an additional message, use a HttpMessageHandler that checks for the response status code. If the status code is OK, add the message. However, the response body has been set already at that point so you will not able to modify it. You might able to add a message as a header.
What is optimal HTTP response Code when not reporting 200 (everything OK) but error in input?
Like, you submit some data to server, and it will response that your data is wrong
using 500 looks more like Server Issue
using 200 with warning/error response text is bad (allowing caching and everything is not OK)
using 204 and returning nothing, is maybe good (but well supported?)
using 404 is wrong if requested path (script) is available and in proper place
We had the same problem when making our API as well. We were looking for an HTTP status code equivalent to an InvalidArgumentException. After reading the source article below, we ended up using 422 Unprocessable Entity which states:
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.
source: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm
Codes starting with 4 (4xx) are meant for client errors. Maybe 400 (Bad Request) could be suitable to this case? Definition in http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says:
"The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. "
409 Conflict could be an acceptable solution.
According to: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
The doc continues with an example:
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
In my case, I would like to PUT a string, that must be unique, to a database via an API. Before adding it to the database, I am checking that it is not already in the database.
If it is, I will return "Error: The string is already in the database", 409.
I believe this is what the OP wanted: an error code suitable for when the data does not pass the server's criteria.
I recommend using 418 when client request something absurd that the server can't process. Like the server is a teapot but client is requesting coffee kind of stuff. Here is all the (400–499) client side error messages: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses
404 - Not Found - can be used for The URI requested is invalid or the resource requested such as a user, does not exists.
When communicating with our REST webservice, an http response with status code of 304 is returned to indicate that the resource requested hasn't changed. However our WP7 application, using the HttpWebRequest class, the phone is taking exactly 2 minutes before this type of response is successfully read.
HttpWebRequest request = HttpWebRequest.Create("path/to/unchanged/resource") as HttpWebRequest;
request.Method = "GET";
request.BeginGetResponse(
new AsyncCallback(
(aysncResult) => {
// response is read correctly here... 120 seconds later
}), null);
I can see that the webservice is responding immediately with 304 and no body data, the request itself is not timing-out and our application is able to successfully handle other response codes [404, 201 etc]. Could it be a Silverlight browser "caching" issue?
Can anyone confirm that they've seen this before, or have any thoughts on the issue?
Cheers,
Alasdair.
== Additional Information ==
As a result of WP7 restricting certain request headers, we use a custom [If-Modified-Since] header for all our resource requests. This custom header [X-If-Modified-Since] is recognised by the firewall in front of the webservice and modified back to the standard header. I'm unsure if this is related to the issue described above.
Answered my own question in case anyone is interested or facing a similar problem.
We eventually created a work around by configuring our webservice to respond with an OK (200) http status code, and writing the actual response code in a custom header X-Http-Status. On the client side when we parse the response, if this custom header exist then we take this to being the actual status code and continue with the business logic from there.
This allows us to potentially deal with any additional status codes that the Windows Phone handles differently.
The cause of the issue is still unknown, although we strongly suspect that since this is a NOT MODIFIED (304) code, some caching is happening at some low level layer in Silverlight before the response is made available to us.