Explain the PATCH method and JSON Patch (RFC 6902)

• PATCH – an HTTP method that applies a partial modification to a resource, sending only the changes rather than the entire representation.
• JSON Patch (RFC 6902) – a standard JSON format using Content-Type: application/json-patch+json that expresses changes as an ordered array of operation objects.
• Operations – each object has an op (add, remove, replace, move, copy, test), a path in JSON Pointer syntax, and optionally a value.
• Atomic – all operations apply in order and atomically; if any fails, the entire patch is rejected and the resource is unchanged.
• Test operation – asserts a value at a path matches an expected value, enabling optimistic concurrency without server-side locking.
• JSON Merge Patch (RFC 7396) – a simpler alternative where a partial object is sent; present fields are set and explicit null deletes a field.

What is the PATCH method?

PATCH is an HTTP method that applies a partial modification to a resource. Unlike PUT, which replaces the entire resource, PATCH sends only the changes. The method itself does not dictate the body format: it just means "partial update." Two standard formats fill that gap: JSON Merge Patch (RFC 7396) and JSON Patch (RFC 6902).

// PATCH sends only the fields to change.
// PATCH /api/v1/beneficiaries/BEN-77
// Content-Type: application/merge-patch+json
// {"nickname": "Landlord"}
// → Only nickname changes; accountNumber, ifsc, etc. remain untouched.

What is JSON Patch (RFC 6902)?

JSON Patch is a standard format defined in RFC 6902 for expressing changes to a JSON document as an ordered array of operations. The content type is application/json-patch+json. Each operation object has an op field naming the operation, a path field in JSON Pointer syntax, and sometimes a value.

• The six operations are:
• add – adds a new member to an object or inserts into an array.
• remove – deletes a field or array element.
• replace – changes an existing value to a new one.
• move – moves a value from one path to another.
• copy – duplicates a value to another path.
• test – asserts a value at a path equals an expected value; if not, the entire patch fails.

// A JSON Patch document (Content-Type: application/json-patch+json)
// [
//   {"op": "test",    "path": "/nickname",  "value": "Rajesh"},
//   {"op": "replace", "path": "/nickname",  "value": "Landlord"},
//   {"op": "remove",  "path": "/ifsc"},
//   {"op": "add",     "path": "/nominees/-", "value": {"name": "Priya"}}
// ]

How does JSON Patch differ from JSON Merge Patch?

JSON Merge Patch (RFC 7396) is simpler: you send a partial JSON object where present fields are set and an explicit null deletes a field. JSON Patch (RFC 6902) is more expressive: it supports ordered operations, array manipulation, move, copy, and the test operation for optimistic concurrency.

| Feature | JSON Merge Patch (RFC 7396) | JSON Patch (RFC 6902) |
|---|---|---|
| Content-Type | application/merge-patch+json | application/json-patch+json |
| Format | Partial JSON object | Array of operation objects |
| Delete a field | Set field to null | {"op": "remove", "path": "/field"} |
| Array manipulation | Replace entire array | Insert, remove, move individual elements |
| Conditional update | Not supported | test operation |
| Ordering | No ordering of changes | Operations applied in order |
| Complexity | Simple | More expressive |

// JSON Merge Patch: simple partial object.
// PATCH /api/v1/beneficiaries/BEN-77
// Content-Type: application/merge-patch+json
// {"nickname": "Landlord", "ifsc": null}
// → Sets nickname to "Landlord", deletes ifsc.

// JSON Patch: ordered operations with test.
// PATCH /api/v1/beneficiaries/BEN-77
// Content-Type: application/json-patch+json
// [
//   {"op": "test",    "path": "/nickname", "value": "Rajesh"},
//   {"op": "replace", "path": "/nickname", "value": "Landlord"},
//   {"op": "remove",  "path": "/ifsc"}
// ]

How do you apply JSON Patch in Java?

In Java you use the JSON-P (Jakarta JSON Processing) API. You parse the patch into a JsonPatch, parse the target resource into a JsonObject, and call patch.apply(target). The operations are applied in order and atomically.

package com.bank.service;

import jakarta.json.*;
import java.io.StringReader;

public class BeneficiaryPatchService {

    public String applyPatch(String patchJson, String resourceJson) {
        JsonArray patchArray = Json.createReader(new StringReader(patchJson)).readArray();
        JsonPatch patch = Json.createPatchBuilder(patchArray).build();
        JsonObject target = Json.createReader(new StringReader(resourceJson)).readObject();
        JsonObject patched = patch.apply(target); // atomic: all or nothing
        return patched.toString();
    }
}

How does the test operation enable optimistic concurrency?

The test operation asserts that a value at a given path matches an expected value. If the assertion fails, the entire patch is rejected and the resource is unchanged. This gives optimistic concurrency without server-side locking: Priya includes a test that the nickname still equals "Rajesh," so her rename only happens if nobody changed it underneath her.

// Test operation for optimistic concurrency:
// [
//   {"op": "test",    "path": "/version", "value": 7},
//   {"op": "replace", "path": "/nickname", "value": "Landlord"}
// ]
// If version is still 7, the replace proceeds.
// If someone bumped version to 8, the test fails → 409 Conflict, nothing changes.

What are the security concerns with JSON Patch?

JSON Patch is powerful but harder to validate and secure than a plain DTO, because the client can target arbitrary paths. You must restrict which paths are patchable so a client cannot replace /balance directly or modify /role to escalate privileges.

package com.bank.service;

import java.util.Set;

public class PatchValidator {

    private static final Set<String> ALLOWED_PATHS = Set.of(
            "/nickname", "/phoneNumber", "/nominees/-");

    public void validate(String patchJson) {
        // Parse patch and check each operation's path against the whitelist.
        // Reject if any path is not in ALLOWED_PATHS.
        // This prevents clients from patching /balance or /role.
    }
}

When should you use JSON Patch vs JSON Merge Patch?

Use JSON Merge Patch for most internal APIs where partial updates are simple: set a few fields, maybe delete one with null. Use JSON Patch when you need ordered operations, array element manipulation, the test operation for optimistic concurrency, or move and copy operations. In banking, JSON Patch's test operation is valuable for safe concurrent profile edits.

// Decision: which format to use?
// Simple field updates → JSON Merge Patch (simpler, less code)
// Array manipulation, conditional updates → JSON Patch (more expressive)
// Optimistic concurrency → JSON Patch test operation

What are common mistakes with PATCH?

A common mistake is treating PATCH as idempotent when it may not be. Another is not distinguishing between "field is null" and "field is absent" in a merge patch, which loses the ability to delete a field. A third is not validating paths in a JSON Patch, allowing clients to modify sensitive fields.

// Wrong: no path validation – client can patch /balance.
@PatchMapping("/beneficiaries/{id}")
public Beneficiary patch(@PathVariable String id, @RequestBody String patchJson) {
    return patchService.apply(id, patchJson); // Any path accepted!
}

// Correct: validate paths before applying.
@PatchMapping("/beneficiaries/{id}")
public Beneficiary patch(@PathVariable String id, @RequestBody String patchJson) {
    patchValidator.validate(patchJson); // Rejects disallowed paths
    return patchService.apply(id, patchJson);
}