Q1 of 37 · API testing
What is the difference between PUT and PATCH?
Short answer
Short answer: PUT replaces the entire resource — fields you don't send are typically wiped. PATCH applies a partial update — only the fields in the request body change. PUT is idempotent by spec; PATCH usually is, but it depends on the patch document.
Detail
Both are HTTP update verbs but they have different semantics. PUT is a full replace: the request body represents the new state of the resource, and any fields the server expects but doesn't see are reset to defaults or null. PUT /users/42 with { name: "Alice" } could leave the user with no email, depending on the API's contract.
PATCH is a partial update: only the fields you send are changed; everything else stays as-is. PATCH /users/42 with { name: "Alice" } updates the name and leaves email, role, and other fields untouched. There are formal patch document formats (JSON Patch RFC 6902, JSON Merge Patch RFC 7396) but most APIs treat PATCH as "merge the body into the resource."
Idempotency — sending the same request multiple times produces the same final state — is required for PUT by HTTP spec. PATCH is usually idempotent, but it doesn't have to be (e.g. PATCH /counter with { "op": "increment" } is not).
For testing, the practical implication is: when validating PUT, also verify that omitted fields are reset; when validating PATCH, verify omitted fields are preserved. Both are common bugs.
// EXAMPLE
# Original resource: { id: 42, name: "Alice", email: "a@x.com", role: "admin" }
# PUT replaces — omitted fields reset
curl -X PUT https://api.example.com/users/42 \
-H "Content-Type: application/json" \
-d '{ "name": "Alice B." }'
# Resulting state: { id: 42, name: "Alice B.", email: null, role: null }
# PATCH merges — omitted fields preserved
curl -X PATCH https://api.example.com/users/42 \
-H "Content-Type: application/json" \
-d '{ "name": "Alice B." }'
# Resulting state: { id: 42, name: "Alice B.", email: "a@x.com", role: "admin" }