Visual RFC.
ALL RFCs / RFC 6902
Read the RFC ↗
RFC 6902 / JSON PATCH

Test values and commit an HTTP patch atomically

05

test compares JSON values without editing them. A failed operation means the patch is not successful; HTTP PATCH must not leave partial changes.

DIAGRAMRead RFC section 4.6 ↗
RFC 6902 · § 4.6EXAMPLE
4 / 4
Test values and commit an HTTP patch atomicallyClient, patch processor and stored-resource lifelines show HTTP PATCH arriving, private count42working state while stored count1stays unchanged, a failed number42versus string42test stopping before commit with store1unchanged, and a separate successful numeric42test allowing count42commit. Intermediate changes are not exposed. The picture distinguishes JSON Patch SHOULD terminate/SHALL NOT successful from HTTP mandatory atomicity.HTTP PATCH · publish all changes or noneClientProcessorStored JSON42 = 42all operations succeedcount: 42AlternativeContent-Type: application/json-patch+json[ {"op":"replace","path":"/count","value":42}, {"op":"test","path":"/count","value":42} ]test compares values · it does not edit them
04
Commit only the alternative successful patch.

Change the test’s value to numeric42. The test passes without editing, and the all-successful HTTP patch commits count42.

Source for this drawing: RFC 6902 · Read RFC section 4.6 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 8259 JSON RFC 6901 JSON Pointer RFC 5789 HTTP PATCH

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Successful earlier operations do not make a failed HTTP PATCH partly successful.

  • The test operation MUST contain value and succeeds only when the target has the same JSON type and is equal by the RFC’s rules. Numbers compare numerically; strings compare characters; arrays compare in order; object member ordering and insignificant whitespace do not matter. Number42 does not equal string"42".
  • On a violated requirement or unsuccessful operation, JSON Patch evaluation SHOULD terminate and the entire patch SHALL NOT be deemed successful. HTTP PATCH adds the atomicity requirement from RFC5789§2: the server MUST apply all changes atomically and MUST NOT apply any if the whole patch fails.
  • The failed HTTP example replaces count1 with42 in private working state, then tests for string"42". The stored resource stays count1. The last state is an alternative successful numeric42test, which permits committing42. HTTP error status selection depends on the failure; JSON Patch does not mandate one code for every error.
DETAILS

This is schematic server staging, not a required implementation architecture. HTTP headers use Content-Type: application/json-patch+json. For base-dependent patches, clients SHOULD use a conditional request such as If-Match (RFC5789§2); test alone is not authentication or authorization. Protect patch contents and enforce application permissions; the old-browser warning in RFC6902§7 is historical, not a current browser-share statistic.

Read the RFC section ↗

All chapters in RFC 6902

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗