HTTP Methods Explained: GET, POST, PUT, DELETE & PATCH (with Examples)

HTTP methods (also called HTTP request methods or HTTP verbs) are standardized actions that indicate the desired operation to perform on a given resource. In this article, we focus on eight commonly used HTTP methods in RESTful APIs: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, and TRACE. These methods map closely to CRUD (Create, Read, Update, Delete) operations and form the backbone of client-server communication on the web.

HTTP Methods at a Glance

Safe means the method does not modify server-side state. Idempotent means making the same request multiple times has the same effect on server-side state as making it once.

Quick Summary List

1. GET — Retrieves data without side effects
2. POST — Submits data to create a new resource
3. PUT — Replaces an entire existing resource
4. PATCH — Applies partial modifications to a resource
5. DELETE — Removes the specified resource
6. HEAD — Identical to GET but returns only headers
7. OPTIONS — Returns the HTTP methods supported by a URL
8. TRACE — Echoes the received request for debugging

What Are HTTP Methods in APIs?

HTTP (Hypertext Transfer Protocol) methods are standardized actions that clients (such as browsers, mobile apps, or CLI tools) use to interact with resources on a server. In RESTful APIs, these methods map to CRUD operations, making them essential for managing data:

• Create → POST
• Read → GET
• Update → PUT or PATCH
• Delete → DELETE

When you browse a website, your browser sends a GET request to retrieve the page content. When you submit a form, a POST request sends the data to the server. When you change your profile settings, a PUT or PATCH request updates your information. This predictable mapping is what makes REST APIs intuitive and easy to work with.

Why Are HTTP Methods Important in API Design?

1. Standardization and Clarity

HTTP methods provide a consistent framework for defining actions. GET retrieves data; POST is commonly used to create resources. This standardization makes APIs intuitive — any developer can understand an endpoint's purpose by looking at the HTTP method alone.

2. Resource Management

Each HTTP method corresponds to a specific action on a resource:

• GET /users/123 → Retrieve user 123
• POST /users → Create a new user
• PUT /users/123 → Replace all fields of user 123
• PATCH /users/123 → Update specific fields of user 123
• DELETE /users/123 → Remove user 123

This clear mapping reduces ambiguity and ensures efficient resource management.

3. Scalability and Maintainability

Proper use of HTTP methods enhances API scalability. GET requests can be cached by CDNs and browsers because they are safe and idempotent. PUT and DELETE are idempotent, making them safe to retry on network failures. This separation of concerns enables APIs to handle high traffic without compromising reliability.

All 8 HTTP Methods Explained (with Examples)

GET: Retrieve Data

Purpose: Retrieve data from the server without modifying resources.

Best Practices:

• Use query parameters for filtering, sorting, and pagination (e.g., ?page=2&limit=10).
• Never include sensitive data in URLs (e.g., passwords or API keys).
• GET requests must be idempotent — repeating the same request should not cause additional state changes, even if the response may differ over time.
• Return 200 OK with the resource in the response body.

Example:

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

Response:

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

{
  "id": 123,
  "name": "John Doe",
  "email": "john@example.com"
}

POST: Create or Submit Data

Purpose: Create a new resource or submit data to the server.

Best Practices:

• Use POST for non-idempotent operations (e.g., creating a new user).
• Include proper error handling (e.g., return 400 Bad Request for invalid input).
• Return 201 Created with the Location header pointing to the new resource.

Example:

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

{
  "name": "John Doe",
  "email": "john@example.com"
}

Response:

HTTP/1.1 201 Created
Location: /users/124
Content-Type: application/json

{
  "id": 124,
  "name": "John Doe",
  "email": "john@example.com"
}

PUT: Replace a Resource Entirely

Purpose: Replace an existing resource with a complete new representation.

Best Practices:

• PUT requests must be idempotent — repeating the same request has the same effect.
• Use PUT for full resource updates (send all fields, not just changed ones).
• Return 200 OK for successful updates or 204 No Content if no response body is needed.
• If the resource does not exist, PUT may create it (return 201 Created).

Example:

PUT /users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Doe",
  "email": "jane@example.com",
  "role": "admin"
}

This request replaces all fields of user 123 with the provided values. Any field not included in the request body may be set to null or default values.

PATCH: Partially Update a Resource

Purpose: Apply partial modifications to an existing resource.

Best Practices:

• Use PATCH when you only need to update specific fields (e.g., changing a user's email without resending their entire profile).
• PATCH is not guaranteed to be idempotent (though it can be designed to be).
• Return 200 OK with the updated resource in the response body.
• Use JSON Merge Patch (application/merge-patch+json) or JSON Patch (application/json-patch+json) for structured updates.

Example (JSON Merge Patch):

PATCH /users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/merge-patch+json

{
  "email": "jane.new@example.com"
}

This request updates only the email of user 123 — all other fields remain unchanged.

What Is the Difference Between PUT and PATCH?

This is one of the most common questions in API design:

Rule of thumb: Use PUT when the client has the complete updated resource. Use PATCH when the client only knows what changed.

DELETE: Remove a Resource

Purpose: Remove a resource from the server.

Best Practices:

• DELETE must be idempotent — deleting a resource multiple times should have the same effect.
• Return 204 No Content for successful deletion.
• Return 404 Not Found if the resource does not exist.
• Consider soft deletes (marking as deleted rather than removing) for data that may need recovery.

Example:

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

Response:

HTTP/1.1 204 No Content

HEAD: Retrieve Headers Only

Purpose: Identical to GET but returns only the HTTP headers — no response body.

Best Practices:

• Use HEAD to check if a resource exists without downloading its content.
• Use HEAD to inspect Content-Length, Last-Modified, or ETag headers before making a full GET request.
• HEAD requests must be safe and idempotent.

Example:

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

Response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 85
Last-Modified: Mon, 17 Mar 2025 10:00:00 GMT

Common use cases: Checking if a large file exists before downloading, validating cache freshness, monitoring API endpoint availability.

OPTIONS: Discover Supported Methods

Purpose: Returns the HTTP methods and communication options supported by a given URL.

Best Practices:

• OPTIONS is used heavily in CORS (Cross-Origin Resource Sharing) preflight requests.
• Return an Allow header listing all supported methods.
• Use OPTIONS to build self-documenting APIs.

Example:

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

Response:

HTTP/1.1 200 OK
Allow: GET, POST, OPTIONS
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

TRACE: Diagnostic Loop-Back Test

Purpose: Echoes the received request back to the client, allowing you to see what intermediate proxies or gateways may have modified.

Best Practices:

• TRACE is primarily a debugging tool — it is rarely used in production APIs.
• Disable TRACE in production to prevent cross-site tracing (XST) attacks.
• Most API gateways and web servers disable TRACE by default.

Example:

TRACE /users HTTP/1.1
Host: api.example.com

Security warning: TRACE can be exploited in XST attacks to steal credentials from HTTP headers. Always disable it in production. API gateways like Apache APISIX block TRACE requests by default.

Common Mistakes and How to Avoid Them

1. Misusing HTTP Methods

Mistake: Using GET for operations that modify data (e.g., GET /users/123/delete). Solution: Always use the correct method — DELETE for deletions, POST for creation, PUT/PATCH for updates. GET requests must never have side effects.

2. Ignoring Idempotency

Mistake: Designing non-idempotent PUT or DELETE endpoints (e.g., a DELETE that decrements a counter). Solution: Ensure that repeating the same PUT or DELETE request has the same effect. This makes your API resilient to network retries.

3. Returning Incorrect Status Codes

Mistake: Returning 200 OK for every response, including errors. Solution: Use appropriate status codes — 201 Created for POST success, 204 No Content for DELETE, 400 Bad Request for invalid input, 404 Not Found for missing resources.

4. Overloading POST for Everything

Mistake: Using POST for all operations, including reads, updates, and deletes. Solution: Use the semantically correct HTTP method. POST is only for creation and non-idempotent operations.

5. Confusing PUT and PATCH

Mistake: Using PUT to update a single field, sending an incomplete resource representation. Solution: Use PATCH for partial updates. Use PUT only when you have the complete replacement resource.

HTTP Methods and API Gateways

An API gateway can enforce correct HTTP method usage across all your APIs:

• Route by method: Direct GET requests to read replicas and POST/PUT/PATCH to write endpoints.
• Method restrictions: Block unsafe methods (PUT, DELETE) on public endpoints that should be read-only.
• CORS handling: Automatically respond to OPTIONS preflight requests without hitting your backend.
• Rate limiting by method: Apply stricter rate limits to write operations (POST, PUT, DELETE) than reads (GET).

API gateways like Apache APISIX and API7 Enterprise provide built-in support for method-based routing, rate limiting, and security policies.

Frequently Asked Questions

How many HTTP methods are there?

The HTTP Semantics specification (RFC 9110), along with RFC 5789 for PATCH, defines 8 standard methods: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, and TRACE. Additionally, WebDAV extends HTTP with methods like PROPFIND, COPY, MOVE, and LOCK for distributed file management.

What is the difference between PUT and PATCH?

PUT replaces an entire resource with a complete new representation — all fields must be included in the request body. PATCH applies partial modifications, updating only the specified fields while leaving the rest unchanged. Use PUT when you have the full resource; use PATCH when you only need to change specific attributes.

What are safe and idempotent HTTP methods?

Safe methods (GET, HEAD, OPTIONS, TRACE) do not modify server-side state — they are read-only operations. Idempotent methods (GET, PUT, DELETE, HEAD, OPTIONS, TRACE) produce the same result whether called once or multiple times. POST and PATCH are neither safe nor guaranteed idempotent.

Can GET requests have a request body?

Technically, the HTTP specification does not forbid a body in GET requests, but it is strongly discouraged. Most HTTP libraries, proxies, and servers ignore or reject GET request bodies. If you need to send complex query parameters, use URL query strings or switch to POST with a request body.

What HTTP method should I use to update a resource?

Use PUT when replacing the entire resource (you send all fields). Use PATCH when updating specific fields (you send only what changed). If your API only supports full replacements, use PUT. If clients frequently update individual attributes, support PATCH for efficiency.

Conclusion

HTTP methods are the cornerstone of RESTful API design. The nine standard HTTP methods — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE, and CONNECT — provide a predictable, standardized vocabulary for client-server communication. By using the correct method for each operation, following idempotency rules, and returning appropriate status codes, you build APIs that are intuitive, scalable, and maintainable.

Next Steps

Deepen your API development knowledge with these related guides:

• RESTful API Best Practices — Learn how to design REST APIs that correctly leverage HTTP methods for clean, intuitive endpoints.
• OpenAPI Specification — Document your HTTP methods, parameters, and responses in the industry-standard OpenAPI format.
• What Is an API Key? — Secure your API endpoints with key-based authentication, commonly applied per HTTP method.
• What Is an API Gateway? — See how API gateways enforce method-based routing, rate limiting, and security at scale.
• Token Bucket vs Leaky Bucket Rate Limiting — Understand the algorithms behind method-aware rate limiting in production APIs.
• Postman API Development Environment — Test all HTTP methods interactively with the most popular API development tool.

Eager to deepen your knowledge about API gateways? Follow our LinkedIn for valuable insights delivered straight to your inbox!

If you have any questions or need further assistance, feel free to contact API7 Experts.