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 VariantExpected Answer (.NET 10 / C# 14)
In ASP.NET Core APIs:
- PUT: Replaces the entire resource. The request body must contain all required fields of the object.
- 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
Statusfrom “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-Matchheaders to prevent concurrent update conflicts). - Is PUT idempotent? (Answer: Yes, by definition).
Expected Answer (Java 26 / Spring Boot)
In Spring Boot REST APIs:
- PUT (
@PutMapping): Replaces the entire resource. The request body is typically mapped to a DTO containing all fields. - PATCH (
@PatchMapping): Performs a partial update.
Real-time Example:
- PUT: Updating a User’s full details.
- PATCH: Updating just the user’s
lastLogintimestamp.
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-patchthat 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):
- PUT: Used to replace the entire resource.
- PATCH: Used for partial updates.
Real-time Example:
- PUT: Updating a User’s full profile.
- PATCH: Updating just the user’s
email_verified_atfield.
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
PUTorPATCHdirectly in HTML forms. PHP frameworks use Method Spoofing (<input type="hidden" name="_method" value="PUT">) to handle this. - Ignoring Idempotency: Implementing
PUTin a way that creates a new resource if it doesn’t exist (this is allowed but often confusing; usuallyPOSTis 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).