It could be 415 Unsupported Media Type according to this list: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.16. 3rd party edit From the current RFC9110 HTTP Semantics The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the content is in a format not supported by this method on the target resource. … Read more
To be consistent I would suggest 400 Bad Request now if your backend apps are capable of identifying when the client gets disconnected or if you reject or close the connection, probably you could return Nginx’ non-standard code 499 or 444. 499 Client Closed Request Used when the client has closed the request before the … Read more
The correct one is 303. I use it and haven’t found any compatibility problems with UAs newer than Netscape 4 (1998, released 17 years ago). If you use 302, you’re risking that UA will re-send POST to the new URL instead of switching to GET. Still, if you’re worried about HTTP/1.0 clients (which don’t support … Read more
If the user has not provided any credentials and your API requires them, return a 401 – Unauthorized. That will challenge the client to do so. There’s usually little debate about this particular scenario. If the user has provided valid credentials but they are insufficient to access the requested resource (perhaps the credentials were for … Read more
400 Bad Request It’s a user error in the request. Unlike with a 403, the client should be allowed to repeat their request, but only after modification: 10.4.1 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. Edit As … Read more
2) Looking back at this, I agree it should probably be either a 204 No Content or maybe a 200 with a body indicating no records or resources could be found depending on the structure returned. 404’s are generally used when the resource URI doesn’t exist or a resource in the URI is not found … Read more
Status 422 (RFC 4918, Section 11.2) comes to mind: 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
Use the RestTemplate#exchange(..) methods that return a ResponseEntity. This gives you access to the status line and headers (and the body obviously). getStatusCode() getHeaders()
What status code should I return if one of these pages was called without required parameters? (and therefore can’t return any content). You could pick 404 Not Found: The server has not found anything matching the Request-URI [assuming your required parameters are part of the URI, i.e. $_GET]. No indication is given of whether the … Read more
If you look at RFC 2616 you’ll see a number of request headers that can be used to apply conditions to a request: If-Match If-Modified-Since If-None-Match If-Range If-Unmodified-Since These headers contain ‘preconditions’, allowing the client to tell the server to only complete the request if certain conditions are met. For example, you use a PUT … Read more