HTTP Request Methods

If you’ve read our previous articles on HTTP protocol fundamentals and HTTP proxies, you already grasp the basics of how HTTP works. You might recall we briefly mentioned GET and POST requests—GET retrieves data from servers, while POST sends data. But did you know HTTP includes other methods like PATCH, PUT, and OPTIONS? Let’s dive deeper into HTTP request methods.

Evolution of HTTP Methods

HTTP methods have expanded over time:

1991: Only GET existed—simple document retrieval, like asking a librarian for a book:TEXTGET /page_to_query.html (No version numbers, headers, or status codes!)
1996 (HTTP/1.0): Added POST (submit data) and HEAD (metadata).
HTTP/1.1: Introduced PUT, DELETE, OPTIONS, TRACE, and CONNECT.
2010 (RFC 5789): PATCH for partial updates (vs. PUT’s full replacements).

This evolution mirrors the web’s growth from static pages to dynamic platforms.

The 9 HTTP Methods Explained

Think of HTTP methods as “verbs” in client-server communication:

GET
- Safe & Idempotent
- Fetches data (e.g., loading Instagram posts, Google searches).
- Like asking a waiter for a menu—read-only.
POST
- Unsafe & Non-idempotent
- Submits data (e.g., posting a tweet, placing an order).
- Accidentally submitting twice? Might create duplicate orders!
PUT
- Idempotent
- Fully replaces a resource (e.g., updating a social media post).
- If the resource doesn’t exist, it’s created.
PATCH
- Non-idempotent
- Partially updates a resource (e.g., editing a post’s text but keeping its image).
DELETE
- Idempotent
- Removes a resource (e.g., deleting a post).
HEAD
- Safe & Idempotent
- Retrieves metadata (e.g., file size) without the full content.
OPTIONS
- Safe & Idempotent
- Lists supported methods for a resource (e.g., “Can I DELETE this?”).
TRACE
- Safe & Idempotent
- Echoes the received request for debugging.
CONNECT
- Unsafe & Non-idempotent
- Establishes secure tunnels (e.g., HTTPS proxies).

HTTP Methods in Action: Restaurant Analogy

Imagine a restaurant where you (client) interact with a waiter (server):

GET: Request a menu (read-only).
POST: Place an order (creates a new pizza order).
PUT: Replace your entire order (“Change my pizza to a burger”).
PATCH: Modify part of the order (“Hold the onions”).
DELETE: Cancel the order.
OPTIONS: Ask, “Can I customize this dish?”
HEAD: “Is my order ready?” (no food delivered).
TRACE: “Repeat my order back to me.”
CONNECT: Reserve a private room (secure tunnel).

Safety & Idempotency

Method	Safe?	Idempotent?	Use Case
GET	✅	✅	Fetch data
POST	❌	❌	Submit data
PUT	❌	✅	Full update
PATCH	❌	❌	Partial update
DELETE	❌	✅	Remove resource
HEAD	✅	✅	Metadata check
OPTIONS	✅	✅	List allowed actions
TRACE	✅	✅	Debugging
CONNECT	❌	❌	Secure tunnel

Key Definitions:

Safe: No server-side changes (e.g., GET).
Idempotent: Repeat requests = same effect (e.g., PUT).

Why Method Choice Matters

Using only POST for everything is like speaking a language with one verb (“do”):

TEXTPOST /api/getUser     ❌ Unclear  
POST /api/deleteUser  ❌ Confusing

RESTful Best Practices:

TEXTGET    /api/users/123  # Fetch user  
PUT    /api/users/123  # Update full profile  
PATCH  /api/users/123  # Update email only  
DELETE /api/users/123  # Delete user

Benefits:

Semantic clarity.
Enables caching (GET is cacheable; POST isn’t).

Next Up: HTTP Status Codes

Now that you’ve mastered HTTP methods, stay tuned for our deep dive into status codes (e.g., 200 OK, 404 Not Found) to decode server responses!