Skip to content
beginner Phase · HTTP and Web Fundamentals

PUT

Deep dive into the PUT method for replacing resources.

20m
0 problems
Topic Progress 0%

The PUT Method

PUT replaces an entire resource with new data. If the resource doesn't exist, PUT can create it.

PUT Characteristics

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

{
  "name": "Alice Updated",
  "email": "alice.new@example.com",
  "role": "admin"
}

→ Not safe: Modifies server state
→ Idempotent: Same request = same final state
→ Not cacheable by default
→ Has a request body (full resource)

PUT vs POST

Aspect PUT POST
Purpose Replace resource Create resource
Idempotent Yes No
URL Specific (/users/123) Collection (/users)
Body Full resource New resource data
Duplicate Same result Creates duplicates

PUT Examples

# Replace a user
PUT /api/users/123
Content-Type: application/json
{
  "name": "Alice Updated",
  "email": "alice@example.com",
  "role": "superadmin"
}

# Create or replace (idempotent)
PUT /api/config/theme
Content-Type: application/json
{"color": "dark", "font": "monospace"}

PUT Design Best Practices

  1. Client specifies the URL — PUT uses the full resource URL
  2. Send the complete resource — PUT replaces the entire object
  3. Return 200 OK (updated) or 201 Created (new)
  4. Validate the entire resource — All required fields must be present
  5. Handle missing resources — Create or return 404

HTTP Best Practices

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 PUT 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

Practice Problems

0 / 3 solved
Implement PUT

Design and implement a solution for PUT in a backend system. Consider scalability, error handling, and production readiness.

Solution
// PUT implementation
// Key aspects: validation, error handling, logging, testing

public class PUT {
    // Production-ready implementation
}
PUT Edge Cases

Identify and handle edge cases for PUT. What happens under high load, with invalid input, or during failures?

Solution
// Edge case handling:
// 1. Null/empty input -> validation
// 2. High load -> rate limiting, queuing
// 3. Failures -> retries, circuit breaker
// 4. Concurrent access -> locks, idempotency
PUT Testing Strategy

Write a testing strategy for PUT. Include unit tests, integration tests, and performance tests.

Solution
// Test plan:
// - Unit: 80% coverage target
// - Integration: API contracts
// - Performance: latency, throughput
// - Chaos: failure injection

Quiz

1. What is the key difference between PUT and PATCH?

Question 1 options

2. Why is PUT idempotent?

Question 2 options

3. What is a common mistake when implementing PUT?

Question 3 options

Flashcards

Question

What does PUT do?

Answer

Replaces an entire resource — idempotent, not safe

Question

PUT vs PATCH?

Answer

PUT replaces entire resource; PATCH updates specific fields

Question

PUT best practices

Answer

Follow SOLID principles, write clean code, test thoroughly, document decisions, and monitor in production.

Revision Notes

Key Takeaways

  • 1. PUT replaces the entire resource
  • 2. PUT is idempotent — same request = same result
  • 3. Client specifies the URL for PUT
  • 4. PUT vs PATCH: full replace vs partial update

Interview Tips

  • Know when to use PUT vs PATCH
  • Understand idempotency of PUT

Cheat Sheet

PUT

  • Purpose: Replace entire resource
  • Properties: Idempotent, Not safe
  • Body: Complete resource (all fields required)
  • vs PATCH: PUT = full replace, PATCH = partial update