HTTP Status 204 (No Content) indicates that the server has successfully fulfilled the request and that there is no content to send in the response payload body.
The server might want to return updated meta-information in the form of entity headers, which, if present, SHOULD be applied to the current document’s active view if any.
The 204 response MUST NOT include a message-body and thus is always terminated by the first empty line after the header fields.
1. Cacheable
By default, 204 (No Content) the response is cacheable. If caching needs to be overridden then the response must include cache respective cache headers.
For example, you may want to return status 204 (No Content) in UPDATE operations where request payload is large enough not to transport back and forth. The user agent will send the payload to the server to update the resource.
If the operation is successful, the server will respond with 204 to indicate the success so that client application can update its UI to inform the user about the operation’s success.
It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.
2. Resolving lost update problem
With status 204, the server may also include an HTTP header ETag to let the client validate client-side resource representation before making a further update on the server – to avoid the lost update problem.
Lost update problem happens when multiple people edit a resource without knowledge of each other’s changes.
In this scenario, the last person to update a resource “wins,” and previous updates are lost.
ETags can be used in combination with the If-Match header to let the server decide if a resource should be updated. If ETag does not match then the server informs the client via a 412 (Precondition Failed) response.
Reference: 204 No Content
In a REST API’s world, is it outlined in the specifications somewhere if one ought to return a 204 HTTP Status code ever in response to a GET request?
If a resource does not exist – 404 should be returned. If a collection of resources do not exist or conform to the specified filters – Is it 200 OK, as the resource DOES exist in the form of an empty database table, or rather 204 No Content, as again, the resource does exist in some form, but there’s no content to return?
Right now I’m on camp that a 204 should never be returned in response to a GET request in a REST API for a resource. When you fetch a resource – it either exists (HTTP 200 OK), or it doesn’t. (HTTP 404 NOT FOUND) – but I’m not sure if the specifications state the same. HTTP 204 would then be used only in controller endpoints.
Thanks!
I generally only return a 204 with PUT requests. Maybe sometimes on a POST, depending on the circumstances.
Hi for a request i am returning a certain type of Object say a City object, now if i make a request for a resource which doesn’t exists now how to handle the no content request? Remember i am returning a City Object.
that’s a 404, not a 204
Depends on what you asked for:
If you requested a list of a sub-resource then I would return a 204 – No content
(e.g. https://api.somebookstore.com/authors/123/books)
If you requested a single (sub-)resource then I would return a 404 – Not found
(e.g. https://api.somebookstore.com/authors/123/books/345)
If you’re requesting a collection (e.g. https://api.somebookstore.com/authors/123/books) I would return:
404 if /authors/123 does not exist
200 with an empty collection otherwise
I would not ever return a 204 in response to a GET