Why PATCH for partial updates in Rest API? - Purpose & Use Cases

The Big Idea

What if you could fix just one thing without breaking everything else?

The Scenario

Imagine you have a user profile with many details like name, email, address, and phone number. You want to update just the phone number. Without PATCH, you have to send the entire profile data again, even if only one piece changes.

The Problem

This full update approach is slow and risky. It wastes time and data by sending unchanged information. It can also accidentally overwrite data if you miss something, causing errors and frustration.

The Solution

PATCH lets you send only the changes you want to make. You update just the phone number without touching the rest. This saves time, reduces errors, and makes your app faster and smarter.

Before vs After

✗ Before

PUT /users/123
{
  "name": "Alice",
  "email": "[e-mail]",
  "phone": "123-4567"
}

✓ After

PATCH /users/123
{
  "phone": "987-6543"
}

What It Enables

It enables efficient, safe updates by changing only what really needs to change.

Real Life Example

When you update your profile picture on a social app, PATCH updates just the image link without resending your entire profile details.

Key Takeaways

PATCH updates only parts of data, not everything.

This saves bandwidth and reduces mistakes.

It makes apps faster and easier to maintain.

Practice

1. What is the main purpose of using the PATCH method in REST APIs?

easy

A. To update only specific fields of a resource without sending the entire data

B. To create a new resource on the server

C. To delete a resource completely

D. To retrieve data from the server

Solution

1. Step 1: Understand HTTP methods

   HTTP methods like GET, POST, PUT, DELETE, and PATCH have different purposes. PATCH is designed for partial updates.

2. Step 2: Identify PATCH behavior

   PATCH sends only the fields that need to be changed, unlike PUT which requires the full resource data.

3. Final Answer:

   To update only specific fields of a resource without sending the entire data -> Option A

4. Quick Check:

   PATCH updates parts only [OK]

Hint: PATCH updates parts, not whole resource [OK]

Common Mistakes:

• Confusing PATCH with PUT which replaces full resource
• Thinking PATCH creates new resources
• Using PATCH to delete resources

2. Which of the following is the correct way to send a PATCH request to update a user's email using JSON?

easy

A. PATCH /users/123 {"email": "[e-mail]"}

B. PATCH /users/123 {"username": "newuser"}

C. GET /users/123 {"email": "[e-mail]"}

D. DELETE /users/123 {"email": "[e-mail]"}

Solution

1. Step 1: Identify HTTP method and endpoint

   PATCH is used to update part of the resource at /users/123.

2. Step 2: Check JSON body for correct field

   The JSON body contains only the field to update, here "email" with new value.

3. Final Answer:

   PATCH /users/123 {"email": "[e-mail]"} -> Option A

4. Quick Check:

   PATCH + partial JSON body = correct syntax [OK]

Hint: PATCH with only fields to update in JSON body [OK]

Common Mistakes:

• Using GET or DELETE instead of PATCH
• Sending unrelated fields in PATCH body
• Trying to update username when email is asked

3. Given this PATCH request body to update a product:

{"price": 19.99}

What will be the result if the original product data was

{"name": "Book", "price": 25.00, "stock": 10}

?

medium

A. {"name": "Book", "price": 25.00, "stock": 10}

B. {"price": 19.99}

C. {"name": "Book", "price": 19.99, "stock": 10}

D. {"name": "Book", "stock": 10}

Solution

1. Step 1: Understand PATCH partial update

   PATCH updates only the fields sent, here "price" changes to 19.99.

2. Step 2: Combine unchanged fields with updated field

   Fields not in PATCH body remain unchanged, so "name" and "stock" stay the same.

3. Final Answer:

   {"name": "Book", "price": 19.99, "stock": 10} -> Option C

4. Quick Check:

   PATCH updates price only, others unchanged [OK]

Hint: PATCH changes only sent fields, keeps others [OK]

Common Mistakes:

• Replacing entire object instead of partial update
• Removing fields not in PATCH body
• Ignoring updated field in result

4. You send this PATCH request to update a user's profile:

{"email": "[e-mail]", "age": "twenty"}

The server expects age as an integer. What is the likely problem?

medium

A. The PATCH request will succeed and update both fields

B. The server will delete the age field from the user profile

C. The server will ignore the age field and update only email

D. The server will reject the request due to invalid data type for age

Solution

1. Step 1: Check data types in PATCH body

   "age" is sent as string "twenty" but server expects integer.

2. Step 2: Understand server validation

   Most servers validate data types and reject requests with invalid types.

3. Final Answer:

   The server will reject the request due to invalid data type for age -> Option D

4. Quick Check:

   Invalid data type causes rejection [OK]

Hint: Check data types match server expectations [OK]

Common Mistakes:

• Assuming server auto-converts wrong types
• Thinking PATCH ignores invalid fields silently
• Believing PATCH deletes fields on error

5. You have a REST API for managing tasks with fields: title, completed, and priority. You want to mark a task as completed without changing other fields. Which PATCH request body is best?

hard

A. {"title": "", "completed": true, "priority": null}

B. {"completed": true}

C. {"completed": true, "priority": "high"}

D. {"title": "New Task"}

Solution

1. Step 1: Identify minimal update needed

   Only the "completed" field needs to change, so send only that.

2. Step 2: Avoid sending unrelated or empty fields

   Sending empty or null fields may overwrite data unintentionally.

3. Final Answer:

   {"completed": true} -> Option B

4. Quick Check:

   Send only changed fields in PATCH body [OK]

Hint: Send only fields you want to update in PATCH [OK]

Common Mistakes:

• Sending all fields even if unchanged
• Sending empty or null values accidentally
• Using PUT instead of PATCH for partial update