PATCH

PATCH applies partial modifications to a resource. Unlike PUT, you only send the fields you want to change.

PATCH Characteristics

PATCH /api/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "email": "alice.updated@example.com"
}

→ Not safe: Modifies server state
→ Not idempotent (in general)
→ Not cacheable by default
→ Has a request body (partial resource)

PATCH vs PUT

Aspect	PATCH	PUT
Purpose	Partial update	Full replacement
Body	Only changed fields	Complete resource
Idempotent	Generally no	Yes
Network efficiency	More efficient	Less efficient

PATCH Examples

# Update only email
PATCH /api/users/123
Content-Type: application/json
{"email": "new@example.com"}

# Update multiple fields
PATCH /api/orders/456
Content-Type: application/json
{"status": "SHIPPED", "trackingNumber": "1Z999AA10123456784"}

# JSON Patch (RFC 6902)
PATCH /api/users/123
Content-Type: application/json-patch+json
[
  {"op": "replace", "path": "/email", "value": "new@example.com"},
  {"op": "remove", "path": "/phone"}
]

Making PATCH Idempotent

While PATCH isn't inherently idempotent, you can make it idempotent by:

• Storing the full state and re-applying the same changes
• Using a unique request ID to deduplicate

// Idempotent PATCH (replaces with same result)
PATCH /api/users/123
{"email": "new@example.com"}
// Server stores: "email update from old to new"
// Same request again → no-op (already applied)

PATCH Design Best Practices

1. Return the updated resource after PATCH
2. Support JSON Merge Patch (RFC 7396) for simple updates
3. Consider JSON Patch (RFC 6902) for complex operations
4. Validate partial updates — Ensure required fields aren't removed

Methods

• GET: Read (safe, idempotent)
• POST: Create
• PUT: Replace (idempotent)
• PATCH: Partial update
• DELETE: Remove (idempotent)

Headers

• Content-Type: Body format
• Cache-Control: Caching rules
• Authorization: Authentication
• Accept: Desired response format

Status Codes

• 2xx: Success
• 3xx: Redirection
• 4xx: Client error
• 5xx: Server error

Key Points

• Understanding PATCH is essential for production systems
• Always consider scalability and maintainability
• Test thoroughly before deploying to production
• Monitor performance and set up alerting

Common Patterns

1. Validation: Always validate input at the boundary
2. Error Handling: Use structured error responses
3. Logging: Log key events for debugging
4. Testing: Unit, integration, and load tests
5. Documentation: Keep docs updated with code changes