HTTP Methods: GET, POST, PUT, PATCH, DELETE

HTTP methods (often called verbs) tell the server what kind of action the client wants to perform on a resource. Choosing the right method is the single most visible sign of a well-designed REST API. In this lesson we cover the five methods you will use daily, plus the two properties that explain when each is appropriate: safety and idempotency.

GET: Read Data

GET retrieves a representation of a resource and must never change server state. Fetching a list of products, reading one user profile, downloading a report: all GET.

http

GET /api/products/42 HTTP/1.1
Host: api.shopcraft.com

GET requests should not have a request body. All input travels in the URL path and query string, which also makes GET responses easy to cache.

POST: Create Data (and More)

POST submits data to a resource collection, typically creating a new item. The server decides the new resource identity and usually responds with 201 Created plus a Location header.

http

POST /api/products HTTP/1.1
Content-Type: application/json

{"name": "Mechanical Keyboard", "price": 89.99}

POST is also the catch-all for actions that do not map cleanly to CRUD, such as POST /api/orders/17/refund. Calling POST twice creates two resources, so clients must be careful about retries.

PUT: Replace Data

PUT fully replaces a resource at a known URL with the representation you send. If you PUT a product object that omits the price field, the price is gone; that is replacement semantics.

http

PUT /api/products/42 HTTP/1.1
Content-Type: application/json

{"name": "Mechanical Keyboard", "price": 79.99, "inStock": true}

Because the client specifies the full final state, sending the same PUT twice leaves the server in the same state. That property is called idempotency.

PATCH: Update Part of a Resource

PATCH applies a partial modification. You send only the fields that change, which is friendlier for large resources and for concurrent editors.

http

PATCH /api/products/42 HTTP/1.1
Content-Type: application/json

{"price": 74.99}

Most real-world APIs accept a plain JSON object of changed fields (merge patch). A more formal option is JSON Patch (application/json-patch+json), which describes operations like add, remove, and replace.

DELETE: Remove Data

DELETE removes the resource at the given URL. Servers commonly reply with 204 No Content on success. Deleting an already-deleted resource typically returns 404, but the end state of the server is the same, so DELETE is still considered idempotent.

Safety and Idempotency Cheat Sheet

Safe methods never modify state: GET (also HEAD and OPTIONS).
Idempotent methods can be repeated without changing the outcome: GET, PUT, DELETE.
POST and PATCH are neither guaranteed safe nor idempotent.

Why does this matter? Networks fail. If a response is lost, a client or proxy can automatically retry an idempotent request without fear of double-charging a card or creating duplicate records. This is why payment APIs like Stripe add idempotency keys to POST requests.

Real-World Mapping to CRUD

A typical resource maps like this: POST /users creates, GET /users lists, GET /users/7 reads, PUT or PATCH /users/7 updates, DELETE /users/7 removes. If you find yourself inventing URLs like /getUsers or /deleteUser?id=7, stop and let the method carry the meaning instead.

Key Takeaways

GET reads, POST creates, PUT replaces, PATCH partially updates, DELETE removes.
Safe methods never change state; idempotent methods can be retried safely.
PUT sends the whole resource, PATCH sends only the changes.
Let methods express intent so URLs can stay noun-based.

Next up: HTTP Status Codes Explained, where we learn how servers communicate success and failure.