Apply operations in array order
01A JSON Patch is an array of edit instructions. Each operation sees the result of the preceding one.
Separate malformed example: increment is not one of the six operation names. It is an error, not a seventh operation.
Source for this drawing: RFC 6902 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
First, agree how to read the message.
An encoding tells a reader how to interpret bytes. A format tells it how values fit together. Correctly reading a value does not make that value trustworthy.
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.
Operation order matters; object member order does not.
- Each operation object MUST have exactly one op and exactly one path. The op MUST be add, remove, replace, move, copy or test; any other operation value is an error. The path is a JSON Pointer string, an address inside the target value.
- Apply operations sequentially in array order, using each result as the next target. Rearranging fields inside an operation object does not change its meaning. Fields not defined for that operation MUST be ignored, rather than interpreted as new instructions.
- add, replace and test require a value member; move and copy require a from pointer. Duplicate op/path members violate the exactly-one rule. Do not rely on a JSON parser silently picking the desired duplicate.
The fictional two-operation patch first creates n, then replaces it. Unlike JSON Merge Patch (RFC7396), this is an ordered instruction array, not an object-shaped merge. The media type is application/json-patch+json; JSON Patch can also be used outside HTTP. Syntax alone grants no permission to edit.
Read the RFC section ↗