HTTP Methods in REST
CRUD Mapping
| HTTP Method | CRUD Operation | Idempotent | Safe |
|---|---|---|---|
| GET | Read | Yes | Yes |
| POST | Create | No | No |
| PUT | Replace (full update) | Yes | No |
| PATCH | Partial update | No* | No |
| DELETE | Delete | Yes | No |
*PATCH can be idempotent if designed carefully.
Method Details
GET — Read Resources
GET /products → 200 OK + list
GET /products/123 → 200 OK + single resource
GET /products/123?include=reviews → 200 OK + expanded
POST — Create Resources
POST /products
Content-Type: application/json
{
"name": "Wireless Mouse",
"price": 29.99
}
→ 201 Created
Location: /products/456
PUT — Full Replacement
PUT /products/123
Content-Type: application/json
{
"name": "Updated Mouse",
"price": 34.99,
"description": "New version"
}
→ 200 OK (all fields required)
PATCH — Partial Update
PATCH /products/123
Content-Type: application/json
{
"price": 39.99
}
→ 200 OK (only changed fields)
DELETE — Remove Resources
DELETE /products/123
→ 204 No Content
Idempotency
GET /products/123 → same result every time ✓
PUT /products/123 → same result every time ✓
DELETE /products/123 → same result every time ✓
POST /products → creates new resource each time ✗
REST Best Practices
Principles
- Stateless communication
- Client-server separation
- Cacheable responses
- Uniform interface
HTTP Methods
- GET: Read (idempotent, safe)
- POST: Create
- PUT: Full update (idempotent)
- PATCH: Partial update
- DELETE: Remove (idempotent)
Status Codes
- 2xx: Success
- 3xx: Redirection
- 4xx: Client error
- 5xx: Server error
Key Points
- Understanding REST HTTP Methods is essential for production systems
- Always consider scalability and maintainability
- Test thoroughly before deploying to production
- Monitor performance and set up alerting
Common Patterns
- Validation: Always validate input at the boundary
- Error Handling: Use structured error responses
- Logging: Log key events for debugging
- Testing: Unit, integration, and load tests
- Documentation: Keep docs updated with code changes
Practice Problems
Design and implement a solution for REST HTTP Methods in a backend system. Consider scalability, error handling, and production readiness.
Solution
// REST HTTP Methods implementation
// Key aspects: validation, error handling, logging, testing
public class RESTHTTPMethods {
// Production-ready implementation
}Identify and handle edge cases for REST HTTP Methods. 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, idempotencyWrite a testing strategy for REST HTTP Methods. Include unit tests, integration tests, and performance tests.
Solution
// Test plan:
// - Unit: 80% coverage target
// - Integration: API contracts
// - Performance: latency, throughput
// - Chaos: failure injectionQuiz
1. Which HTTP method is NOT idempotent?
2. When should you use PATCH over PUT?
3. What is a common mistake when implementing REST HTTP Methods?
Flashcards
Question
What does idempotent mean?
Click to reveal answer
Answer
Same request produces the same result every time
Question
POST vs PUT?
Click to reveal answer
Answer
POST = create new, PUT = replace existing
Question
REST HTTP Methods best practices
Click to reveal answer
Answer
Follow SOLID principles, write clean code, test thoroughly, document decisions, and monitor in production.
Revision Notes
Key Takeaways
- 1. GET=read, POST=create, PUT=replace, PATCH=partial update, DELETE=remove
- 2. Idempotent methods: GET, PUT, DELETE
- 3. POST creates new resources, not idempotent
- 4. Use PATCH for partial updates, PUT for full replacement
Interview Tips
- • Explain idempotency and why it matters
- • Know when to use PUT vs PATCH
Cheat Sheet
HTTP Methods
- GET: Read (idempotent, safe)
- POST: Create (NOT idempotent)
- PUT: Replace (idempotent)
- PATCH: Partial update (may be idempotent)
- DELETE: Remove (idempotent)
- Idempotent: Same result every time