CRUD Operations and HTTP Methods in REST APIs

What You'll Learn

• What CRUD means and where it comes from
• How each CRUD operation maps to an HTTP method
• How to design a complete CRUD endpoint set for any resource
• Common deviations from the standard mapping

Why This Matters

Almost every REST API in the world is a CRUD API at its core: create, read, update, delete resources. Once you internalize this mapping, you can read any API documentation in minutes — because they all follow the same pattern.

Simple Explanation

CRUD stands for Create, Read, Update, Delete — the four basic operations on any data store. REST APIs map these to HTTP methods:

The Standard CRUD Endpoint Set

For any resource — users, posts, orders, products — a REST API typically exposes these six endpoints:

1. Create — POST /resources

POST /users HTTP/1.1
Content-Type: application/json

{"name": "Anita", "email": "anita@example.com"}

HTTP/1.1 201 Created
Location: /users/123

{"id": 123, "name": "Anita", "email": "anita@example.com"}

Status: 201 Created (sometimes 200 OK).
Body: The created resource, usually with the server-assigned ID.
Location header: URL of the new resource.

2. Read (list) — GET /resources

GET /users?role=admin HTTP/1.1

HTTP/1.1 200 OK

[
  {"id": 123, "name": "Anita", "role": "admin"},
  {"id": 456, "name": "Ravi", "role": "admin"}
]

Status: 200 OK.
Body: An array of resources. Usually paginated (we cover this in lesson 19).

3. Read (one) — GET /resources/{id}

GET /users/123 HTTP/1.1

HTTP/1.1 200 OK

{"id": 123, "name": "Anita", "email": "anita@example.com"}

Status: 200 OK, or 404 Not Found if the ID does not exist.

4. Update (full) — PUT /resources/{id}

PUT /users/123 HTTP/1.1
Content-Type: application/json

{"name": "Anita Sharma", "email": "anita.sharma@example.com"}

HTTP/1.1 200 OK

{"id": 123, "name": "Anita Sharma", "email": "anita.sharma@example.com"}

Status: 200 OK, or 201 Created if PUT created a new resource (upsert behavior).
Body: The full new state of the resource. Fields not sent are cleared.

5. Update (partial) — PATCH /resources/{id}

PATCH /users/123 HTTP/1.1
Content-Type: application/json

{"email": "new.email@example.com"}

HTTP/1.1 200 OK

{"id": 123, "name": "Anita", "email": "new.email@example.com"}

Status: 200 OK.
Body: Only the fields to update. Other fields stay unchanged.

6. Delete — DELETE /resources/{id}

DELETE /users/123 HTTP/1.1

HTTP/1.1 204 No Content

Status: 204 No Content (or 200 OK with a confirmation body).
Body: Usually empty.

The Full Endpoint Table

Worked Example — Designing a "Comments" Resource

Suppose you are designing the API for comments on blog posts. The standard CRUD set:

If comments belong to posts, you might use nested URLs:

GET /posts/{postId}/comments        → list comments on a post
POST /posts/{postId}/comments       → add a comment to a post

When Real APIs Deviate

Not every action fits CRUD cleanly. Examples:

• Actions: "Send a password reset email", "Cancel an order", "Publish a post". These are verbs, not CRUD operations. Common patterns:
  • POST /users/{id}/password-reset (action-style endpoint)
  • POST /orders/{id}/cancel
• Long-running operations: "Generate a report". Often:
  • POST /reports returns 202 Accepted with a job ID
  • GET /reports/{jobId} to poll for status
• Bulk operations: "Delete 50 users at once". Often:
  • POST /users/bulk-delete with an array of IDs in the body

These deviations are fine. Pragmatism beats purity.

Common Mistakes

1. Using POST for everything. Some APIs use POST for reads because "GET cannot have a body". Use GET with query parameters instead. It is cacheable, idempotent, and follows the standard.
2. Mixing PUT and PATCH semantics. Sending a partial body to PUT will clear fields you did not include. Be explicit about which method you are using.
3. Returning 200 for creates. The correct status for POST-creating a resource is 201 Created, with a Location header. 200 is acceptable but less informative.
4. Forgetting the Location header on 201. Clients use it to navigate to the new resource. Always include it.
5. Using GET /users/delete/123. GET must not have side effects. Use DELETE /users/123.

Practical Exercise (10 minutes)

Using cURL against JSONPlaceholder, exercise all six CRUD operations on the /posts resource:

# Create
curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"my post","body":"hello","userId":1}'

# Read list
curl https://jsonplaceholder.typicode.com/posts

# Read one
curl https://jsonplaceholder.typicode.com/posts/1

# Update (PUT)
curl -X PUT https://jsonplaceholder.typicode.com/posts/1 \
  -H "Content-Type: application/json" \
  -d '{"id":1,"title":"new","body":"new","userId":1}'

# Update (PATCH)
curl -X PATCH https://jsonplaceholder.typicode.com/posts/1 \
  -H "Content-Type: application/json" \
  -d '{"title":"patched"}'

# Delete
curl -X DELETE https://jsonplaceholder.typicode.com/posts/1

For each, note the response status and body shape.

Mini Challenge

Design the full CRUD endpoint set for a "shopping cart" resource. Think about: what does it mean to "create" a cart? Can you delete a cart? What about adding items to a cart — is that a PUT, PATCH, or a custom action?

Key Takeaways