CRUD → HTTP

System Design FundamentalsEntrynetworkingsystem-design

The Question

How do CRUD operations map to HTTP methods?

What a Strong Answer Covers

• All four mapped. PUT vs PATCH.

Senior-Level Answer

CRUD (Create, Read, Update, Delete) maps onto HTTP methods through REST conventions. The mapping is not one-to-one—HTTP provides more verbs than CRUD has operations—and understanding the nuances prevents common API design mistakes.

**Create → POST (or PUT)**. POST to a collection URL (`POST /articles`) creates a new resource with a server-assigned ID. The response should be `201 Created` with a `Location` header pointing to the new resource. PUT to a specific URL (`PUT /articles/abc`) creates or replaces the resource at that exact URL—used when the client controls the ID (e.g., upserts).

**Read → GET**. `GET /articles` returns a collection; `GET /articles/1` returns a single resource. GET is safe and idempotent, so it can be cached and retried freely. The response is `200 OK` with the representation in the body. If the resource does not exist, return `404 Not Found`.

**Update → PUT or PATCH**. This is where most confusion lives. PUT sends a complete replacement of the resource—the client must include all fields. PATCH sends a partial update—only the changed fields. Use PUT when the client always has the full representation; use PATCH for partial edits (e.g., updating a single status field). Both return `200 OK` with the updated resource, or `204 No Content` when no body is needed.

**Delete → DELETE**. `DELETE /articles/1` removes the resource. Return `204 No Content` on success (no body needed) or `200 OK` if you return the deleted representation. A second DELETE on an already-deleted resource should return `404 Not Found`—the resource is gone.

**Status codes matter**: returning `200` for a creation instead of `201`, or returning `200` for a deletion instead of `204`, technically works but loses semantic signal. Clients that inspect status codes (reverse proxies, monitoring tools, generated SDK clients) rely on this precision.

A consistent, semantically correct CRUD-to-HTTP mapping makes APIs predictable, reduces client bugs, and enables standard tooling (caches, retry logic, API gateways) to work correctly out of the box.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Using POST for updates instead of PUT or PATCH.
• Returning 200 for resource creation instead of 201.
• Not distinguishing PUT (full replacement) from PATCH (partial update).
• Returning 200 with an empty body on delete instead of 204 No Content.

Follow-Up Questions

• When would you use PUT instead of POST for creating a resource? — When the client controls the resource ID—e.g., idempotent upserts where the client provides a UUID.
• What is the difference between returning 200 and 204 for a successful update? — 200 includes the updated resource in the body; 204 signals success with no body—saves bandwidth when the client doesn't need the result.
• How should a REST API handle a PATCH request where one of the provided fields is invalid? — Return 422 Unprocessable Entity with a body describing which fields failed validation.
• How would you design a bulk delete endpoint within REST conventions? — Options: DELETE on a collection URL with a request body (non-standard but used), or a POST /resources/batch-delete action endpoint.

Related Questions

• Redis Caching Patterns
• Vertical vs Horizontal Scaling
• API Versioning
• SLOs vs SLAs
• Availability — Five 9s