HTTP Methods

GET, POST, PUT, DELETE, PATCH & Beyond

At the heart of every web application and API lies the humble HTTP method—also known as an HTTP verb. Methods like GET, POST, PUT, and DELETE instruct servers on how to process client requests: whether to retrieve data, create new resources, update existing entries, or remove them entirely. Yet while these four get most of the attention, the HTTP specification defines a richer set of methods (including PATCH, HEAD, OPTIONS, CONNECT, and TRACE)—each with its own semantics, safety guarantees, and idempotence properties.

Understanding HTTP methods deeply is crucial for:

• API Design: Choosing the right method conveys intent, improves client/server cooperation, and enables proper caching and error handling.
• Security: Knowing which methods are safe vs. potentially destructive guides authentication, authorization, and CSRF protections.
• Performance: Leveraging idempotent, cacheable methods (like GET) with HTTP/2 multiplexing and HTTP/3’s QUIC transport delivers faster, more resilient applications.
• Reliability: Designing with idempotence in mind allows safe retries without unintended side effects.
• Standards Compliance: Following REST and RFC guidelines ensures broad client compatibility and predictable behavior.

In this in‑depth guide, we’ll cover:

1. What Are HTTP Methods? Core definitions, safety, and idempotence.
2. Core CRUD Methods & Their Semantics (GET, POST, PUT, DELETE, PATCH) with real‑world examples and best practices.
3. Lesser‑Known Methods & Special Use Cases: HEAD, OPTIONS, TRACE, CONNECT, WebDAV verbs.
4. Safety, Idempotence & RESTful Patterns: Why it matters for retries and fault tolerance.
5. Status Codes & Method Responses: Aligning codes (200, 201, 204, 404, 405, etc.) with methods.
6. Practical API Design Patterns: URI conventions, conditional requests with ETags, pagination.
7. Performance, Caching & HTTP/2‑3: How modern protocols optimize method usage.
8. Debugging & Developer Tools: Using browser DevTools, curl, Postman, and telnet.
9. FAQs: Quick answers on common method questions.
10. Conclusion: Key takeaways and next steps.

Whether you’re architecting public REST APIs or building internal microservices, this guide will equip you to choose and implement HTTP methods with confidence, clarity, and correctness.

1. What Are HTTP Methods?

HTTP methods are keywords used in the request line that tell the server the intended action on the resource identified by the URI. For example:

GET /users/123 HTTP/1.1

GET /users/123 HTTP/1.1

Here, GET signals “retrieve the resource at /users/123,” without side effects.

Safety and Idempotence

Two key properties define method behavior:

• Safe methods guarantee no modification of resources; using them for writes violates semantics and can break caching.
• Idempotent methods ensure that issuing the same request N times results in the same outcome as once—enabling safe retries in unreliable networks.

Methods lacking these properties, like POST, can create multiple resources or trigger actions each time they’re called.

REST Guidelines

In RESTful design, methods map to CRUD operations:

• Create → POST
• Read → GET/HEAD
• Update → PUT/PATCH
• Delete → DELETE

Following this mapping aligns your API with client expectations, HTTP standards, and intermediary behaviors like caching proxies.

2. Core CRUD Methods & Their Semantics

GET: Safe Retrieval

• Semantics: Retrieve a representation of a resource without side effects.
• Safe: Yes.
• Idempotent: Yes.
• Cacheable: Yes, by default.

Example: Fetch user data

GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{"id":123,"name":"Alice","email":"alice@example.com"}

GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{"id":123,"name":"Alice","email":"[email protected]"}

Best Practices:

• Use query parameters for filtering: GET /books?author=Rowling&page=2.
• Avoid sending a request body; many servers ignore or reject bodies on GET.
• Implement proper caching headers (ETag, Last-Modified, Cache-Control).

Error Handling:

• 404 Not Found if resource does not exist.
• 400 Bad Request for malformed query parameters.

POST: Create or Process

• Semantics: Submit data to the server to create a subordinate resource or trigger processing.
• Safe: No.
• Idempotent: No.
• Cacheable: No, unless explicit headers indicate so.

Example: Create a new book

POST /books HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"title":"1984","author":"Orwell","year":1949}

HTTP/1.1 201 Created
Location: /books/456
Content-Type: application/json

{"id":456,"title":"1984","author":"Orwell","year":1949}

POST /books HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"title":"1984","author":"Orwell","year":1949}

HTTP/1.1 201 Created
Location: /books/456
Content-Type: application/json

{"id":456,"title":"1984","author":"Orwell","year":1949}

Best Practices:

• Return 201 Created with a Location header pointing to the new resource.
• Include a response body with representation or an identifier.
• For operations that don’t create persistent resources (e.g., form submissions), 200 OK or 202 Accepted may be appropriate.

Error Handling:

• 400 Bad Request for validation errors.
• 409 Conflict if resource already exists.
• 422 Unprocessable Entity for semantic errors.

PUT: Upsert or Replace

• Semantics: Fully replace the state of a resource at the given URI with the supplied representation. Can also create if resource doesn’t exist (idempotent “upsert”).
• Safe: No.
• Idempotent: Yes.
• Cacheable: No by default.

Example: Update book 456

PUT /books/456 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"id":456,"title":"Nineteen Eighty-Four","author":"Orwell","year":1949}

HTTP/1.1 200 OK
Content-Type: application/json

{"id":456,"title":"Nineteen Eighty-Four","author":"Orwell","year":1949}

PUT /books/456 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"id":456,"title":"Nineteen Eighty-Four","author":"Orwell","year":1949}

HTTP/1.1 200 OK
Content-Type: application/json

{"id":456,"title":"Nineteen Eighty-Four","author":"Orwell","year":1949}

Best Practices:

• Require the full representation; omitted fields may be reset to defaults.
• Use 204 No Content if you don’t return a body after an update.
• Include If-Match header with an ETag to avoid lost updates (optimistic concurrency).

Error Handling:

• 400 Bad Request for invalid JSON.
• 404 Not Found if updating non‑existent resource and no upsert.
• 412 Precondition Failed if ETag precondition fails.

DELETE: Remove Resource

• Semantics: Delete the resource identified by the URI.
• Safe: No.
• Idempotent: Yes (deleting something twice has same end state).
• Cacheable: No.

Example: Delete book 456

DELETE /books/456 HTTP/1.1
Host: api.example.com

HTTP/1.1 204 No Content

DELETE /books/456 HTTP/1.1
Host: api.example.com

HTTP/1.1 204 No Content

Best Practices:

• Return 204 No Content when the resource is successfully deleted and no entity body is returned.
• 404 Not Found if the resource didn’t exist.
• Support bulk deletion via query parameters: DELETE /books?author=Orwell.

PATCH: Partial Update

• Semantics: Apply partial modifications to a resource.
• Safe: No.
• Idempotent: Typically yes if designed carefully, but can be non‑idempotent if server transforms state cumulatively.
• Cacheable: No.

Example: Update only the title

PATCH /books/456 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"title":"1984 (Revised Edition)"}

HTTP/1.1 200 OK
Content-Type: application/json

{"id":456,"title":"1984 (Revised Edition)","author":"Orwell","year":1949}

PATCH /books/456 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"title":"1984 (Revised Edition)"}

HTTP/1.1 200 OK
Content-Type: application/json

{"id":456,"title":"1984 (Revised Edition)","author":"Orwell","year":1949}

Best Practices:

• Use JSON Patch (application/json-patch+json) for precise operations (add, remove, replace).
• Or simple partial resource representations for smaller updates.
• Document which fields are updatable.

Error Handling:

• 400 Bad Request for invalid patch document.
• 409 Conflict if patch conflicts with current state.
• 422 Unprocessable Entity for semantic errors.

3. Lesser‑Known Methods & Special Use Cases

HEAD: Metadata Only

• Behavior: Identical to GET but without a response body.
• Use Case: Check resource existence, content length, headers (Last-Modified, ETag) before downloading.

HEAD /files/large.zip HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Length: 104857600
Accept-Ranges: bytes

HEAD /files/large.zip HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Length: 104857600
Accept-Ranges: bytes

OPTIONS: Discover Capabilities

• Behavior: Returns allowed methods and server capabilities, often in the Allow header.
• CORS Preflight: Browsers send OPTIONS with Access-Control-Request-Method before actual cross‑origin requests.

OPTIONS /api/books HTTP/1.1
Host: api.example.com

HTTP/1.1 204 No Content
Allow: GET, POST, OPTIONS
Access-Control-Allow-Methods: GET, POST, OPTIONS

OPTIONS /api/books HTTP/1.1
Host: api.example.com

HTTP/1.1 204 No Content
Allow: GET, POST, OPTIONS
Access-Control-Allow-Methods: GET, POST, OPTIONS

TRACE: Diagnostic Echo

• Behavior: Echoes back the request for debugging.
• Security: Often disabled due to potential cross‑site tracing attacks.

CONNECT: Proxy Tunneling

• Behavior: Establishes a tunnel to the server, typically for HTTPS through an HTTP proxy.
• Use Case: CONNECT example.com:443 HTTP/1.1 opens a raw TCP tunnel.

WebDAV & Extensions

• WebDAV Methods: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK.
• Use Case: File system operations over HTTP.

WebDAV adds richer semantics for collaborative editing but requires dedicated server support.

4. Safety, Idempotence & RESTful Best Practices (≈300 words)

Design Implications

• Retries & Fault Tolerance: Idempotent methods can be safely retried on network failures (PUT, DELETE).
• Caching: Only safe and idempotent methods (GET, HEAD) should be cached by default.
• Security: CSRF protections focus on unsafe methods (POST, PUT, DELETE).
• API Clarity: Using the correct method communicates intent—disallowing misuses (e.g., POST for deletes) by returning 405 Method Not Allowed.

5. Status Codes & Method Responses

Aligning methods with status codes ensures predictable client behavior:

405 Method Not Allowed

When a valid endpoint exists but doesn’t support the invoked method:

POST /users/123 HTTP/1.1
Host: api.example.com

HTTP/1.1 405 Method Not Allowed
Allow: GET, PUT, DELETE

POST /users/123 HTTP/1.1
Host: api.example.com

HTTP/1.1 405 Method Not Allowed
Allow: GET, PUT, DELETE

Clients can examine the Allow header to adjust behavior.

6. Practical API Design Patterns

CRUD Convention

GET    /books         → List books
POST   /books         → Create a book
GET    /books/{id}    → Retrieve book
PUT    /books/{id}    → Replace book
PATCH  /books/{id}    → Update book partially
DELETE /books/{id}    → Delete book

GET    /books         → List books
POST   /books         → Create a book
GET    /books/{id}    → Retrieve book
PUT    /books/{id}    → Replace book
PATCH  /books/{id}    → Update book partially
DELETE /books/{id}    → Delete book

Conditional Requests with ETag

• Server returns ETag: "abc123" with resource.
• Client caches response, then later:

GET /books/456 HTTP/1.1 If-None-Match: "abc123"

GET /books/456 HTTP/1.1 If-None-Match: "abc123"

• Server returns 304 Not Modified if unchanged—saves bandwidth.

Pagination & Filtering

• Pagination:
  GET /books?page=2&limit=20
• Filtering:
  GET /books?author=Orwell&year=1949

Bulk Operations

• Bulk Delete:
  DELETE /books?author=Orwell
• Bulk Update (PATCH array payload).

7. Performance, Caching & HTTP/2‑3

Caching with GET

• Mark static or infrequently changing data as cacheable.
• Use Cache-Control: public, max-age=3600, immutable for assets.

HTTP/2 & HTTP/3 Benefits

• Multiplexing: Parallel requests over one connection—ideal for many small GETs.
• Header Compression: Reduces size of repetitive headers in API calls.
• QUIC (HTTP/3): Faster TLS handshake and loss recovery on lossy networks.

By sticking to safe, idempotent methods for repeatable requests, you maximize the advantages of modern protocol features.

8. Debugging & Developer Tools

Browser DevTools

• Network Tab: Inspect requests, responses, timings, headers, and bodies.
• Throttling: Simulate slow 3G or offline to test fallback behavior.

CLI Tools

• curl:

curl -i -X PATCH -H "Content-Type: application/json" -d '{"title":"New"}' https://api.example.com/books/456

curl -i -X PATCH -H "Content-Type: application/json" -d '{"title":"New"}' https://api.example.com/books/456

• httpie: Human‑friendly HTTP client:

http PATCH https://api.example.com/books/456 title="New Title"

http PATCH https://api.example.com/books/456 title="New Title"

• telnet: For raw HTTP/1.0 debugging:

telnet api.example.com 80 GET /books/456 HTTP/1.0 Host: api.example.com

telnet api.example.com 80 GET /books/456 HTTP/1.0 Host: api.example.com

Common Pitfalls

• Missing Content-Type on POST/PUT/PATCH leads to 415 Unsupported Media Type.
• CORS errors when Access-Control-Allow-Methods omits the method.
• 404 vs 405 confusion when wrong URI vs wrong method.

9. FAQs

Q1. When should I choose PUT vs POST?

• POST for creating subordinate resources or processing actions.
• PUT for full replacement or upsert at a known URI—clients specify the new resource’s URI.

Q2. Can POST be idempotent?
While POST is defined as non‑idempotent, you can design POST endpoints to be idempotent by rejecting duplicate payloads (e.g., idempotency keys). However, it’s clearer to use PUT or PATCH when idempotence is essential.

Q3. Is using PATCH safe?
PATCH is neither inherently safe nor idempotent. If your partial updates depend solely on the provided payload, PATCH can be idempotent; otherwise, consider PUT.

Q4. Should DELETE return 204 or 200?

• 204 No Content: Preferred when there’s no response body.
• 200 OK: If you include a response body (e.g., confirmation document).

Q5. What about WebDAV methods?
Methods like PROPFIND and MKCOL extend HTTP for file operations. Only use them when interacting with WebDAV‑compliant servers—regular REST APIs won’t understand them.

Conclusion

A deep understanding of HTTP methods underpins robust, predictable, and performant web APIs. By aligning methods with CRUD semantics—using GET for retrieval, POST for creation, PUT/PATCH for updates, and DELETE for removal—you convey clear intent to clients, proxies, and caches. Leveraging method properties (safety, idempotence) enables secure retries, efficient caching, and streamlined error handling. Don’t overlook the lesser‑known verbs (HEAD, OPTIONS, CONNECT) for metadata checks and proxy tunneling, and design with proper status codes and headers (Location, ETag, Allow) to guide clients. Embrace HTTP/2’s multiplexing and HTTP/3’s low‑latency transport by keeping your request patterns safe and cacheable. With disciplined method usage, you will craft clean, scalable, and standards‑compliant APIs—essential for modern web and microservice architectures.

About The Author

Pavan Kalyan

See author's posts