The items with code “200 (cache)” were fulfilled directly from your browser cache, meaning that the original requests for the items were returned with headers indicating that the browser could cache them (e.g. future-dated Expires or Cache-Control: max-age headers), and that at the time you triggered the new request, those cached objects were still stored … Read more
Since Express 4.0, there’s a dedicated sendStatus function: res.sendStatus(404); If you’re using an earlier version of Express, use the status function instead. res.status(404).send(‘Not found’);
An overview of 301, 302 and 307 The RFC 7231, the current reference for semantics and content of the HTTP/1.1 protocol, defines the 301 (Moved Permanently) and 302 (Found) status code, that allows the request method to be changed from POST to GET. This specification also defines the 307 (Temporary Redirect) status code that doesn’t … Read more
params is for GET-style URL parameters, data is for POST-style body information. It is perfectly legal to provide both types of information in a request, and your request does so too, but you encoded the URL parameters into the URL already. Your raw post contains JSON data though. requests can handle JSON encoding for you, … Read more
Per the Express (Version 4+) docs, you can use: res.status(400); res.send(‘None shall pass’); http://expressjs.com/4x/api.html#res.status <=3.8 res.statusCode = 401; res.send(‘None shall pass’);
I did not know the answer so asked the ASP.NET team here. So the trick is to change the signature to HttpResponseMessage and use Request.CreateResponse. [ResponseType(typeof(User))] public HttpResponseMessage GetUser(HttpRequestMessage request, int userId, DateTime lastModifiedAtClient) { var user = new DataEntities().Users.First(p => p.Id == userId); if (user.LastModified <= lastModifiedAtClient) { return new HttpResponseMessage(HttpStatusCode.NotModified); } return request.CreateResponse(HttpStatusCode.OK, … Read more
Here’s an example: @GET @Path(“retrieve/{uuid}”) public Response retrieveSomething(@PathParam(“uuid”) String uuid) { if(uuid == null || uuid.trim().length() == 0) { return Response.serverError().entity(“UUID cannot be blank”).build(); } Entity entity = service.getById(uuid); if(entity == null) { return Response.status(Response.Status.NOT_FOUND).entity(“Entity not found for UUID: ” + uuid).build(); } String json = //convert entity to json return Response.ok(json, MediaType.APPLICATION_JSON).build(); } Take … Read more
If “validation failure” means that there is some client error in the request, then use HTTP 400 (Bad Request). For instance if the URI is supposed to have an ISO-8601 date and you find that it’s in the wrong format or refers to February 31st, then you would return an HTTP 400. Ditto if you … Read more
Status 422 seems most appropiate based on the spec. 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 … Read more
400 Bad Request would now seem to be the best HTTP/1.1 status code for your use case. At the time of your question (and my original answer), RFC 7231 was not a thing; at which point I objected to 400 Bad Request because RFC 2616 said (with emphasis mine): The request could not be understood … Read more