* Removes line length limit from Status Code Markdown This will make the data easier to use when we develop the API, it needs to be consistent, arbitrary new lines (especially in text format) will be a major issue, so some sort of workaround would have to be implemented, easier to simply fix the source files. * Removes line length limit from misc. Markdown files
2.0 KiB
set | code | title | references | ||||||
---|---|---|---|---|---|---|---|---|---|
2 | 204 | No Content |
|
The server has successfully fulfilled the request and that there is no additional content to send in the response payload body.
Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.
For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.
The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.
For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.
A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.
A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls1.
- 1 Calculating Heuristic Freshness RFC7234 Section 4.2.2
- Source: RFC7231 Section 6.3.5