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 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.
204 (No Content) response is cacheable. If caching needs to be overridden then 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, and 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.
Resolving lost update problem
With status 204, server may also include HTTP header
ETag to let the client validate client side resource representation before making further update on server – to avoid 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 server informs the client via a
412 (Precondition Failed) response.
Reference: 204 No Content