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.
Related
I want to check that i got all the content and not just a part of it. If the http header is OK, does it mean that all the content is also OK?
So far i have been using Bash and wget command.
Look for status code 200. According the W3's documentation, status code 200 received in response to a GET requests means the request succeeded and the response is and is returned in the response.
Someone could write an API that returns garbage and still sends status code 200. If you are just getting a file/document from a Web server, then the status codes are probably very trustworthy.
If you want to have a look at the response body to check all your content is there you could use tools like Fiddler or IExplorer F12, wireshark. As #ahoffer mentions if status is 200 ok then the server is giving you what you requested.
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.
I've a spring integration http inbound-gateway. I'd like to return specific http status codes in different cases of use. Is there any way to specify the httpStatus in the response???
I tried with a excepion type router where each exception is a specific http status code, but i don't know how to set the status code in the response and I don't find any help about it in the documentation.
Thanks!
User a <header-enricher/> (or other means) to put the status in the org.springframework.integration.http.HttpHeaders.STATUS_CODE header of the reply message. (The header name is "http_statusCode" but using the constant is generally recommended).
The code can either be an HttpStatus object, or an Integer/String with the status code you want to return.
Please open a 'Documentation' JIRA issue https://jira.springsource.org/browse/INT
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).
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.