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.
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