HTTP Methods: GET, POST, PUT, DELETE

When you click a link, submit a form, or update your profile on any website, your browser is silently speaking a language that has powered the World Wide Web since 1991. That language is HTTP—the Hypertext Transfer Protocol—and at its grammatical core are HTTP methods, the verbs that express what action you want to perform on a resource.

HTTP methods are deceptively simple on the surface. A GET retrieves data. A POST submits data. But beneath this simplicity lies a rich semantic framework that, when properly understood and applied, enables the construction of scalable, cacheable, and interoperable web systems. Misunderstanding these methods leads to security vulnerabilities, broken caches, confused APIs, and systems that scale poorly.

This page provides a comprehensive, authoritative examination of the four most critical HTTP methods: GET, POST, PUT, and DELETE. We will explore not just what they do, but why they're designed this way, how their semantic properties enable architectural patterns like REST, and what happens when developers use them incorrectly.

Before diving into individual methods, we must understand the conceptual framework that governs all HTTP methods. This framework is defined in RFC 9110 (HTTP Semantics) and distinguishes methods by two fundamental properties: safety and idempotency.

The Resource-Centric Model

HTTP operates on a resource-centric model. Every URL identifies a resource—which could be a document, an image, a user profile, or an abstract concept like "today's weather forecast." HTTP methods express the action you wish to perform on that resource.

This is fundamentally different from Remote Procedure Call (RPC) models, where you call functions with parameters. In HTTP:

• The URL identifies the thing you're acting upon
• The method specifies the action you want to perform
• The headers provide metadata about the request
• The body (when present) contains payload data

Safety Defined

A method is safe if it does not cause any state change on the server.

When a client makes a safe request, it has reasonable confidence that no modification will occur on the server. This doesn't mean the server does nothing—it might log the request, update analytics counters, or trigger side effects. But from the client's perspective, the resource itself remains unchanged.

Why safety matters:

• Browsers can prefetch safe resources without user consent
• Search engines can crawl links without fear of modifying data
• Proxies can cache and serve safe requests
• Users can click safe links without confirmation dialogs

Idempotency Defined

A method is idempotent if making the same request multiple times produces the same end state as making it once.

This is subtly different from "returns the same response." Consider deleting a resource:

• First DELETE: Resource is removed → 200 OK
• Second DELETE: Resource already gone → 404 Not Found

The responses differ, but the final state is identical—the resource is deleted. That's idempotency.

Why idempotency matters:

• Network failures are common; clients can safely retry idempotent requests
• Load balancers can replay requests to failed backends
• Message queues can have at-least-once delivery semantics
• Clients don't need complex deduplication logic

The GET method is the workhorse of the World Wide Web. When you type a URL into your browser's address bar or click a hyperlink, you're issuing a GET request. It's so fundamental that many developers take it for granted—yet misunderstanding GET leads to security vulnerabilities, broken bookmarks, and non-cacheable applications.

Formal Definition (RFC 9110)

The GET method requests transfer of a current selected representation for the target resource.

In plain language: GET asks the server for a copy of the resource identified by the URL.

Core Properties

The Anatomy of a GET Request

Request Line: GET /api/users/12345 HTTP/1.1

• Method: GET
• Request-Target: /api/users/12345 (the resource path)
• HTTP-Version: HTTP/1.1

Essential Headers:

• Host: Required in HTTP/1.1; identifies the target domain
• Accept: Preferred content types (content negotiation)
• Accept-Encoding: Supported compression algorithms
• If-None-Match: ETag for conditional requests (caching)
• Authorization: Credentials for protected resources

GET and Caching: The Power Multiplier

GET's safety and idempotency enable aggressive caching, which is HTTP's killer performance feature. Consider a typical web application:

1. User A requests /products/shoes
2. Server generates response, includes Cache-Control: max-age=3600
3. Response cached by CDN, browser
4. Users B, C, D request same URL within the hour
5. CDN serves cached response—server never touched

Result: One database query serves thousands of users.

This only works because GET is safe. If GET could modify data, caches couldn't serve responses to different users—each might expect different modifications.

Query Parameters: Filtering and Pagination

GET requests commonly include query parameters for filtering, sorting, and pagination. These are appended to the URL after a ? character:

GET /api/products?category=electronics&sort=price&order=asc&page=2&limit=20

Parameter Types:

• Filtering: category=electronics, minPrice=100, inStock=true
• Sorting: sort=price, order=asc|desc
• Pagination: page=2, limit=20, or cursor-based: cursor=eyJpZCI6MTAwfQ
• Field Selection: fields=id,name,price (reduce payload)
• Expansion: include=reviews,manufacturer (embed related resources)

URL Length Limitations

While HTTP doesn't specify a URL length limit, practical constraints exist:

Best Practice: Keep URLs under 2,000 characters. If you need more complex queries, consider POST with a request body for query specification (though this breaks REST conventions).

The POST method is HTTP's general-purpose tool for submitting data to a server for processing. Unlike GET, POST is designed to be neither safe nor idempotent—it explicitly acknowledges that the request may modify server state and that repeating it may produce different results.

Formal Definition (RFC 9110)

The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.

This intentionally vague definition reflects POST's versatility. POST can:

• Create new resources
• Submit form data for processing
• Append data to existing resources
• Trigger complex server-side operations
• Anything else that doesn't fit other methods

Core Properties

POST for Resource Creation

In RESTful APIs, POST is the standard method for creating new resources when the server determines the resource's identifier. Consider:

POST /api/articles

The client is saying: "Create a new article; you (the server) decide its ID."

The server responds with:

• 201 Created status code
• Location header pointing to the new resource (/api/articles/9876)
• Often the created resource in the response body

Contrast with PUT: If the client knows the target ID, PUT is more appropriate:

PUT /api/articles/9876

The Duplicate Submission Problem

POST's non-idempotency creates a classic problem: What happens if a network error occurs after the server processes the request, but before the client receives the response?

Client: POST /orders (create order)
  ↓ (request reaches server)
Server: Creates order #5001, sends 201 response
  ↓ (network drops response)
Client: Timeout! Did it work? Retry POST?
  ↓ (client retries)
Server: Creates order #5002 (duplicate!)

Solutions:

1. Idempotency Keys: Client sends a unique key with each request

   POST /orders
   Idempotency-Key: 7a3b2c1d-unique-uuid
   

   Server stores processed keys; rejects duplicates with 409 Conflict.

2. Two-Phase Create:

   • Phase 1: POST to create a "pending" draft
   • Phase 2: PUT to confirm/finalize

3. Client-Generated IDs: Use PUT with client-generated UUID

   PUT /orders/550e8400-e29b-41d4-a716-446655440000
   

Content-Type for POST Requests

POST requests must specify the format of the body data using the Content-Type header. Common values:

POST Response Status Codes

The PUT method requests that the server replace the target resource with the enclosed representation. Unlike POST (which submits data for processing), PUT explicitly states the desired final state of a resource.

Formal Definition (RFC 9110)

The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message content.

This definition highlights PUT's declarative semantics: the client is saying "make this resource look exactly like this."

Core Properties

PUT vs. POST: The Crucial Distinction

The difference between PUT and POST is fundamental to HTTP semantics but often confused:

POST: "Process this data according to your own rules"

• Server determines the outcome
• Server may create resource with server-generated ID
• Semantics are resource-specific
• Not idempotent

PUT: "Make this resource look exactly like this"

• Client specifies the exact target URI
• Request body is the desired final state
• Semantics are uniform across resources
• Idempotent

Example: Creating a user

# POST: Server decides the ID
POST /api/users
{"username": "alice"}
→ 201 Created, Location: /api/users/789

# PUT: Client specifies the ID
PUT /api/users/alice-uuid-12345
{"username": "alice"}
→ 201 Created (if new) or 200 OK (if exists)

PUT Idempotency in Practice

PUT's idempotency is its key advantage for reliability. Consider:

Client: PUT /articles/42 with new content
  ↓ (request reaches server)
Server: Updates article, sends 200 OK
  ↓ (network drops response)
Client: Timeout! Did it work? Safe to retry.
  ↓ (client retries)
Server: Updates article again with same content → 200 OK

The final state is identical whether PUT executed once or twice. This enables:

1. Automatic retry logic in HTTP clients
2. Load balancer replay after backend failures
3. Eventually consistent systems where updates may arrive multiple times
4. Simpler error recovery in distributed systems

Conditional PUT with ETags

To prevent lost updates (two clients updating simultaneously, one overwrites the other), use conditional requests:

PUT /api/documents/42
If-Match: "version-etag-123"

The server only processes the PUT if the current ETag matches. If another client updated the document, the ETag changed, and the server returns:

HTTP/1.1 412 Precondition Failed

The client must then fetch the latest version, merge changes, and retry.

The DELETE method requests that the origin server remove the association between the target resource and its current functionality. It's HTTP's explicit mechanism for resource removal.

Formal Definition (RFC 9110)

The DELETE method requests that the origin server remove the association between the target resource and its current functionality.

Note that DELETE doesn't necessarily require physical deletion—it requests removal from the HTTP-accessible namespace.

Core Properties

DELETE Idempotency: A Subtle Point

DELETE is idempotent because the end state is the same regardless of how many times you send the request: the resource is gone.

Initial State: Resource /users/123 exists

First DELETE:
  → Server removes /users/123
  → Response: 200 OK or 204 No Content
  → State: /users/123 does not exist

Second DELETE:
  → Server looks for /users/123, not found
  → Response: 404 Not Found (or 204 No Content)
  → State: /users/123 still does not exist

Same final state → Idempotent.

Design Choice: Should DELETE on a missing resource return 404 or 204?

Both are valid. 404 is more common; 204 provides cleaner retry semantics.

Soft Delete vs. Hard Delete

Many applications need to retain deleted data for auditing, recovery, or regulatory compliance. Two patterns:

Hard Delete: Resource is physically removed

DELETE FROM users WHERE id = 12345;

• Simple implementation
• Data truly gone (GDPR compliance)
• Cannot be undone

Soft Delete: Resource marked as deleted but retained

UPDATE users SET deleted_at = NOW() WHERE id = 12345;

• Enables undelete/recovery
• Supports audit requirements
• Requires query filters everywhere

Cascading Deletes and Referential Integrity

Deleting a resource may have implications for related resources:

Scenario: DELETE /api/departments/42

What happens to employees in department 42?

API Design Consideration: The API should communicate what will happen:

# Option 1: Fail fast
DELETE /departments/42
→ 409 Conflict: "Cannot delete department with 15 assigned employees"

# Option 2: Explicit cascade
DELETE /departments/42?cascade=true
→ 200 OK: {"deleted": ["department:42", "employees:101-115"]}

# Option 3: Two-step
POST /departments/42/prepare-deletion
→ {"impact": {"employees": 15}, "confirmationToken": "abc123"}
DELETE /departments/42?confirmationToken=abc123

Selecting the correct HTTP method is a design decision with far-reaching implications. This section provides a decision framework for method selection.

Method Properties Summary

           Safe?    Idempotent?    Cacheable?
GET        ✅ Yes     ✅ Yes          ✅ Yes
HEAD       ✅ Yes     ✅ Yes          ✅ Yes
OPTIONS    ✅ Yes     ✅ Yes          ❌ No
TRACE      ✅ Yes     ✅ Yes          ❌ No

POST       ❌ No      ❌ No           ⚠️ If specified
PUT        ❌ No      ✅ Yes          ❌ No
PATCH      ❌ No      ❌ No           ❌ No
DELETE     ❌ No      ✅ Yes          ❌ No

Key Insight: When you need a retriable, safe operation that causes no state change, you must use GET or HEAD. When you need a retriable operation that modifies state, you must use PUT or DELETE. POST should be reserved for operations that are truly non-idempotent (like creating resources with server-generated IDs or triggering complex workflows).

We've explored the four fundamental HTTP methods in depth. Let's consolidate the essential knowledge: