Pattern 1: Field-Presence Flags (The Explicit Opt-In)

This pattern involves augmenting your DTO with additional metadata. Instead of a String name, you have a PatchField<String> name, where PatchField is a wrapper containing the value and a boolean flag indicating if the field was present in the request.

// Example using a simple wrapper
public class PatchField<T> {
    private T value;
    private boolean present = false;

    // Special setter used during deserialization
    public void setValue(T val) {
        this.value = val;
        this.present = true;
    }
    public boolean isPresent() { return present, }
    public T getValue() { return value, }
}

// Your PATCH DTO
public class OrderPatchDTO {
    private PatchField<String> productName;
    private PatchField<BigDecimal> totalAmount;
}

Your update logic becomes explicit: if (dto.getProductName().isPresent()) { entity.setProductName(dto.getProductName().getValue()), }.

The Trade-off: You trade a clean client payload for absolute server-side clarity. Your API contract is precise, but your DTOs and persistence layer become more verbose. This pattern shines in controlled, internal service-to-service communication where you control both ends of the wire.

Pattern 2: JSON Patch (RFC 6902) – The Standardized Operator

Instead of sending a partial document, you send a sequence of operations to apply. This is the essence of JSON Patch.

A request to change a product’s name and explicitly nullify its description would look like:

[
  { "op": "replace", "path": "/productName", "value": "New Product" },
  { "op": "replace", "path": "/description", "value": null }
]

The Power: The intent is unambiguous. null is a first-class value. Omitting a field from the patch array simply means no operation on it. The RFC also elegantly handles complex operations on arrays (add, remove, move), which are nightmarish with a simple DTO approach.

The Reality Check: As noted in the research, library support can be uneven. While there are solid implementations for Java, .NET, and TypeScript, you’re buying into a specific standard. The client payload is more verbose and less human-readable at a glance. However, proponents argue this is the price of correctness. One developer lamented the resistance to adopting the spec, grumbling that engineers often prefer to “hand sling” their own solutions despite the spec existing precisely to avoid these “footguns.””

Pattern 3: The GraphQL Approach: Separating Schema from Transport

GraphQL naturally solves this by design. In a GraphQL mutation, you specify exactly which fields you’re returning, but more importantly for input, your schema can define distinct input types. Advanced codegen tools can produce types where an omitted field is truly absent (undefined in TypeScript/JavaScript), while an explicit null is preserved.

Consider a GraphQL-inspired approach to managing cross-service state coordination. The type system, not convention, governs what can change. This shifts the problem from runtime validation to compile-time (or codegen-time) safety. The caveat is you must be in a GraphQL ecosystem, retrofitting this onto a REST API is non-trivial.