Follow representation semantics
04PATCH is an HTTP method that applies a patch document. For state-changing methods, identify what the enclosed representation describes.
In the published 404 example, the enclosed problem details are the representation being described. The digest is not calculated over a nonexistent target book.
Source for this drawing: RFC 9530 · Read RFC section 3.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A PATCH request representation digest is computed on the patch document, not the future patched resource.
- A PATCH request representation digest is computed on the patch document, not the future patched resource.
- In a response that describes request status, Repr-Digest MUST cover the enclosed representation. If there is a referenced resource, it MUST cover that resource’s selected representation according to HTTP semantics.
- Content-Location is representation metadata; Location is not and does not determine Repr-Digest. An error response can describe an error representation instead of the target resource.
The full published byte examples, including indentation and LF, are computationally checked. A 204 can still carry a selected-representation digest when the method semantics identify it; absence of content does not universally mean the representation digest is empty.
Read the RFC section ↗