HTTP Methods

Overview

HTTP methods (also called verbs) tell the server what action a client wants to perform on a resource. Choosing the right method makes an API predictable and lets caches, proxies, and browsers behave correctly. Two key ideas guide the choice: safe methods don't change data, and idempotent methods produce the same result no matter how many times they run.

Syntax / Usage

Each method has an intended purpose. GET reads, POST creates, PUT replaces, PATCH partially updates, and DELETE removes.

GET    /articles/7        # safe, idempotent — read
POST   /articles          # not idempotent — create new
PUT    /articles/7        # idempotent — full replace
PATCH  /articles/7        # partial update
DELETE /articles/7        # idempotent — remove

Examples

A PATCH updates only the fields you send, leaving the rest untouched:

PATCH /articles/7 HTTP/1.1
Content-Type: application/json

{ "title": "Updated Title" }

{
  "id": 7,
  "title": "Updated Title",
  "body": "Original body stays the same"
}

A PUT replaces the entire resource, so omitted fields may be cleared:

PUT /articles/7 HTTP/1.1
Content-Type: application/json

{ "title": "New Title", "body": "New body" }

Common Mistakes

• Using GET to change data — it should never have side effects
• Using POST for updates when PUT or PATCH fits better
• Confusing PUT (full replace) with PATCH (partial update)
• Assuming DELETE is unsafe to retry — it's idempotent, so retries are fine
• Sending a request body with GET, which many servers ignore

See Also

api-design-rest-basics api-design-status-codes api-design-error-handling