Easy8 minWeb Fundamentals
UpdatedAug 2, 2026
Edit

PUT vs PATCH

Why This Is Asked

This tests your knowledge of RESTful API design. Understanding the difference between a full update (PUT) and a partial update (PATCH) is critical for building efficient and standards-compliant web services.

Key Concepts

  • PUT: Replaces the entire resource. If a field is omitted, it’s typically nullified or reset to default.
  • PATCH: Performs a partial update. Only the fields provided are changed; others remain as they were.
  • Idempotency: PUT is idempotent (calling it multiple times with the same data yields the same result); PATCH can be but isn’t always, depending on implementation.

Answers by Technology

+ Add Variant

Expected Answer (.NET 10 / C# 14)

In ASP.NET Core APIs:

  1. PUT: Replaces the entire resource. The request body must contain all required fields of the object.
  2. PATCH: Updates only specific fields. In .NET, this is often implemented using JsonPatchDocument (JSON Patch standard).

Real-time Example:

  • PUT: Updating a User’s full profile (Name, Email, Bio).
  • PATCH: Updating just the User’s Status from “Active” to “Away”.

Why It Matters

Using PATCH reduces bandwidth because you don’t send the entire object. It also prevents “Last-Write-Wins” conflicts where two users update different fields at the same time and accidentally overwrite each other’s changes.

Code Example

// PUT: Full Replace
[HttpPut("{id}")]
public IActionResult UpdateUser(int id, UserUpdateDto userDto)
{
    var user = _repository.Get(id);
    user.Name = userDto.Name; // Full sync
    _repository.Save();
    return NoContent();
}

// PATCH: Partial Update (using Microsoft.AspNetCore.JsonPatch)
[HttpPatch("{id}")]
public IActionResult PatchUser(int id, [FromBody] JsonPatchDocument<User> patchDoc)
{
    var user = _repository.Get(id);
    patchDoc.ApplyTo(user); // Only applies specific ops like "replace"
    _repository.Save();
    return NoContent();
}

Common Mistakes

  • Using PUT for partial updates: This often leads to nullifying fields that the client didn’t intend to change.
  • Complexity of PATCH: Implementing full JSON Patch (RFC 6902) is more complex than a simple PUT. Many developers use a “Partial DTO” approach instead.

Follow-up Questions

  • What is an ETag? (Answer: A version identifier used with If-Match headers to prevent concurrent update conflicts).
  • Is PUT idempotent? (Answer: Yes, by definition).

Expected Answer (Java 26 / Spring Boot)

In Spring Boot REST APIs:

  1. PUT (@PutMapping): Replaces the entire resource. The request body is typically mapped to a DTO containing all fields.
  2. PATCH (@PatchMapping): Performs a partial update.

Real-time Example:

  • PUT: Updating a User’s full details.
  • PATCH: Updating just the user’s lastLogin timestamp.

Why It Matters

Using the correct HTTP method makes your API predictable and follows the principle of least astonishment. PUT is strictly for replacement; PATCH is for modification. This affects how caches and proxies treat the requests.

Code Example

// PUT: Full update
@PutMapping("/users/{id}")
public ResponseEntity<User> updateUser(@PathVariable Long id, @RequestBody UserDTO userDto) {
    User user = service.update(id, userDto); // Replaces all fields
    return ResponseEntity.ok(user);
}

// PATCH: Partial update (often using Map to capture only provided fields)
@PatchMapping("/users/{id}")
public ResponseEntity<User> patchUser(@PathVariable Long id, @RequestBody Map<String, Object> updates) {
    User user = service.partialUpdate(id, updates);
    return ResponseEntity.ok(user);
}

Common Mistakes

  • Using PUT like PATCH: Omitting fields in a PUT request body and expecting them to remain unchanged (they should usually become null).
  • Ignoring Idempotency: Implementing a PUT that has side effects beyond updating the record (PUT should be idempotent).

Follow-up Questions

  • How to handle JSON Patch in Spring? (Answer: By using libraries like json-patch that allow applying RFC 6902 operations to Java objects).
  • Validation: How do you validate a PATCH request? (Answer: Often harder than PUT because you need to validate only the fields that were actually sent).

Expected Answer (PHP 8.5 / Laravel)

In PHP APIs (like Laravel):

  1. PUT: Used to replace the entire resource.
  2. PATCH: Used for partial updates.

Real-time Example:

  • PUT: Updating a User’s full profile.
  • PATCH: Updating just the user’s email_verified_at field.

Why It Matters

Using the correct method impacts how you validate requests. For a PUT, all required fields must be present. For a PATCH, you typically make all fields optional in your validation logic because the client might only send one or two.

Code Example

// Laravel Controller
public function update(Request $request, User $user)
{
    if ($request->isMethod('put')) {
        // Validate ALL fields
        $data = $request->validate([...]);
    } else {
        // Validate only PROVIDED fields
        $data = $request->validate([...]);
    }
    
    $user->update($data);
}

Common Mistakes

  • HTML Form Limitation: Browsers don’t support PUT or PATCH directly in HTML forms. PHP frameworks use Method Spoofing (<input type="hidden" name="_method" value="PUT">) to handle this.
  • Ignoring Idempotency: Implementing PUT in a way that creates a new resource if it doesn’t exist (this is allowed but often confusing; usually POST is for creation).

Follow-up Questions

  • What is Method Spoofing? (Answer: A technique where a POST request includes a special field to tell the server to treat it as a PUT or DELETE).
  • Is PATCH idempotent? (Answer: Not necessarily, though it can be).