Junior Level

Both methods are used to update a resource, but they work differently.

PUT — Full Update

• Replaces the entire resource representation with what the client sent. Fields not present in the request body must be deleted or reset to default values.
• Need to send all fields, even unchanged ones
• If a field is omitted — it will be deleted or set to null

PUT /users/1
{
  "name": "Ivan",
  "age": 30,
  "email": "ivan@example.com"
}

PATCH — Partial Update

• Updates only the fields that were sent
• Saves bandwidth: for a 200-field object, changing one field via PATCH saves ~95% of the request body.

PATCH /users/1
{
  "age": 31
}
// All other fields remain unchanged

Comparison:

Criteria	PUT	PATCH
Data volume	Full object	Only changed fields
Idempotency	Always idempotent	Depends on implementation
SQL analogy	UPDATE all columns	UPDATE specific columns

When PUT is better than PATCH

Use PUT for full replacements of small objects — simpler to implement and unambiguous. Use PATCH for large objects or when multiple clients may modify different fields in parallel.

---

Middle Level

Method Semantics

PUT (Replace)

• Idempotency: Always idempotent. No matter how many times you send the same request — the result is the same
• DB Analogy: UPDATE users SET name=?, age=?, email=? ... (updating all columns)

PATCH (Partial Update)

• Idempotency: Not guaranteed. Depends on implementation
• DB Analogy: UPDATE users SET age = age + 1 (not idempotent) or SET age = 30 (idempotent)

PATCH Specifications

1. JSON Merge Patch (RFC 7386):
   • Client sends JSON: {"age": 31}
   • Server simply merges it with the current object
   • Downside: Hard to delete a field (need to agree that null means deletion)

   Key difference: Merge Patch says “what to change” (declarative), while JSON Patch says “how to change” (sequence of operations: add, remove, replace).

2. JSON Patch (RFC 6902):
   • Client sends an array of instructions:

     [
     { "op": "replace", "path": "/age", "value": 31 },
     { "op": "remove", "path": "/middleName" }
     ]
     

   • Advantage: Atomicity and flexibility. Can add elements to arrays, remove specific fields

Optimistic Locking (ETag)

1. Client receives a resource with header ETag: "v1"
2. Client sends PUT/PATCH with header If-Match: "v1"
3. If ETag became “v2” — server returns 412 Precondition Failed

Diagnostics

• 422 Unprocessable Entity: If PATCH is logically infeasible (e.g., removing a required field)
• Hibernate/JPA: For PATCH, use nullValuePropertyMappingStrategy = IGNORE in MapStruct to avoid accidentally overwriting fields

---

Senior Level

The “Lost Updates” Problem and Optimistic Locking

What if two users simultaneously read a resource (age=20) and decide to update it?

• PUT problem: First updates to 21, second — to 25. First user’s changes are lost.
• PATCH solution: If PATCH does age = age + 1, the result will be 22 (both changes accounted for).

Performance and Highload

• Bandwidth: PATCH saves bandwidth on large objects (profiles with hundreds of fields)
• Validation: PUT is easier to validate (full schema). PATCH requires complex “only sent fields” validation logic
• Reflection in Java: PATCH implementation often requires Jackson JsonNode to determine whether a field was null or absent

Implementing PATCH in Spring

Be careful with merge() in Hibernate. If you create a new object and call merge(), you might accidentally overwrite fields not sent in PATCH, turning it into a broken PUT.

Edge Cases

• If PATCH contains {"op": "add", "path": "/tags", "value": "new"} — this is not idempotent (on retry, another tag will be added)
• For idempotent PATCH, use deterministic operations (replace, remove)

---

Interview Cheat Sheet

Must know:

• PUT replaces the resource entirely — fields not in the request are deleted or nulled
• PATCH updates only sent fields — saves bandwidth on large objects
• PUT is always idempotent; PATCH is idempotent only with deterministic operations
• JSON Merge Patch (RFC 7386) — declarative approach: “what to change”
• JSON Patch (RFC 6902) — imperative approach: array of operations (add, remove, replace)
• Optimistic Locking via ETag + If-Match prevents concurrent update conflicts
• PUT is easier to validate (full schema), PATCH requires complex partial data validation

Frequent follow-up questions:

• What is the Lost Update Problem? — Two clients read and update a resource in parallel; first client’s changes are lost
• How to implement PATCH in Hibernate? — Use nullValuePropertyMappingStrategy = IGNORE in MapStruct
• What does the server return on 412 Precondition Failed? — ETag changed since reading, resource is stale
• When is PUT better than PATCH? — For small objects and when unambiguous full replacement is needed

Red flags (DO NOT say):

• “PATCH is always idempotent” — add to a collection is not idempotent
• “PUT updates only sent fields” — PUT replaces the entire object
• “There’s no difference between PUT and PATCH” — PUT = full replacement, PATCH = partial update
• “Merge Patch and JSON Patch are the same” — Merge Patch is declarative, JSON Patch is a sequence of operations

Related topics:

• [[What is idempotency]]
• [[Which HTTP methods are idempotent]]
• [[What are the main HTTP methods used in REST]]
• [[How to properly name REST endpoints]]