HTTP Methods: GET, POST, PUT, PATCH, DELETE & More

HTTP methods (also called HTTP request methods or HTTP verbs) are standardized actions that indicate the desired operation to perform on a given resource. If you are designing or consuming RESTful APIs, the most common questions are practical ones: when should you use GET vs POST, when is POST vs PUT the right comparison, and how do PUT, PATCH, and DELETE behave when a request is retried?

This guide explains the eight methods defined by HTTP Semantics (RFC 9110), plus PATCH as defined by RFC 5789: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH. You will learn how the methods map to common API operations, which are safe or idempotent, what status codes to return, and how an API gateway can enforce method-based routing and policies.

HTTP Methods at a Glance

Safe means the client is not requesting a state change. Idempotent means multiple identical requests have the same intended effect as one request; the response status and body can still differ. These properties describe method semantics, not a guarantee that every server implementation is correct.

GET vs POST vs PUT vs PATCH vs DELETE: Quick Decision Table

In short: use GET vs POST to decide between reading and creating/submitting, and use POST vs PUT to decide between creating an unknown/new resource and replacing a known resource at a stable URL.

Quick Summary List

1. GET — Retrieves data without requesting a state change
2. POST — Submits data to create a new resource
3. PUT — Creates or replaces state at a known URI
4. PATCH — Applies partial modifications to a resource
5. DELETE — Removes the specified resource
6. HEAD — Uses GET semantics but returns no response content
7. OPTIONS — Returns the HTTP methods supported by a URL
8. TRACE — Performs a diagnostic message loop-back
9. CONNECT — Establishes a tunnel through a proxy

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 user 123 with the supplied representation
• 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 method semantics make APIs easier for clients, caches, gateways, and retry logic to handle correctly. GET responses are cacheable by definition, although cache directives and authorization rules still determine whether a particular response can be reused. PUT and DELETE are idempotent, but clients should still consider timeouts, preconditions, and application-specific side effects before automatically retrying them.

All 9 Core HTTP Methods Explained

GET: Retrieve Data

Purpose: Retrieve data without asking the server to modify the target resource.

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 Request Method: Create or Submit Data

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

A client sends a POST request with request data in the message body, commonly as JSON or form data. Unlike a GET URL, that body is not normally stored in browser history, although applications must still protect sensitive values in logs and developer tools.

Best Practices:

• Use POST when the target resource should process the submitted representation, such as creating a subordinate resource or triggering an action.
• Include proper error handling (e.g., return 400 Bad Request for invalid input).
• When POST creates a resource, return 201 Created and include a Location header when the new resource has an identifier. Other processing outcomes may use 200 OK, 202 Accepted, or 204 No Content.

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: Create or replace the state of a resource at a known URI with the supplied representation.

Best Practices:

• PUT requests must be idempotent — repeating the same request has the same effect.
• Treat the request body as the replacement representation defined by the API contract. Whether omitted fields are rejected, defaulted, or removed is application-specific.
• 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 asks the server to replace the state represented by /users/123 with the supplied representation. The API contract must define how validation and omitted fields are handled.

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 when the response includes the updated representation, or 204 No Content when the update succeeds without a 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 is idempotent in its intended effect. A retry may return a different status, such as 404 Not Found, after the association has already been removed.
• Return 200 OK when the response includes a status or representation, 202 Accepted when deletion is asynchronous, or 204 No Content when deletion completes without a response body.
• A later retry may return 404 Not Found if the resource no longer exists and the API exposes that distinction.
• 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: Uses the same request semantics as GET but returns no response content. A server may omit headers whose values are determined only while generating GET content.

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.
• Include an Allow header when the response is intended to enumerate supported methods. An Allow header is required for a 405 Method Not Allowed response, but not for every possible OPTIONS response.
• 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.
• Verify the behavior of each server and gateway in the request path instead of assuming TRACE is disabled by default.

Example:

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

Security warning: TRACE reflects request data and can expose sensitive fields when a server or intermediary handles it incorrectly. Disable or tightly restrict it unless you have a controlled diagnostic requirement.

CONNECT: Establish a Tunnel

Purpose: Ask a proxy to establish a tunnel to the host and port identified by the request target. CONNECT is most commonly associated with creating a TCP tunnel for HTTPS traffic through an HTTP proxy.

Best Practices:

• Allow CONNECT only to approved destinations and ports.
• Authenticate and log tunnel requests at the proxy boundary.
• Do not expose an unrestricted CONNECT proxy to untrusted clients.

Example:

CONNECT api.example.com:443 HTTP/1.1
Host: api.example.com:443

If the proxy permits the tunnel, it returns a successful 2xx response and then forwards bytes in both directions. CONNECT is not a CRUD method and is uncommon in ordinary REST API resource design.

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: Use the method whose requested semantics match the operation — DELETE for deletions, POST for creation or processing, and PUT/PATCH for updates. A GET endpoint must not ask the server to change resource state; incidental effects such as logging or metrics collection do not change that safety classification.

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: Choose status codes based on the outcome. Examples include 201 Created when POST creates a resource, 202 Accepted for asynchronous processing, 204 No Content for a successful response without a body, 400 Bad Request for invalid input, and 404 Not Found for a missing resource.

4. Overloading POST for Everything

Mistake: Using POST for all operations, including reads, updates, and deletes. Solution: Use the method whose semantics match the operation. POST is appropriate for resource-specific processing, including creation and actions that do not map cleanly to PUT, PATCH, or DELETE.

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?

RFC 9110 defines eight HTTP methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, and TRACE. RFC 5789 defines PATCH, bringing the core set commonly discussed for APIs to nine. The IANA HTTP Method Registry also includes standardized extension methods such as WebDAV's PROPFIND, COPY, MOVE, and LOCK.

What is the difference between GET and POST?

GET retrieves data and should not change server-side state. POST submits data to create a resource or trigger a server-side action, so it usually has a request body and is not idempotent.

What is the difference between POST and PUT?

POST is commonly used when the server decides the new resource URL, such as POST /users. PUT is used when the client updates or replaces a known resource URL, such as PUT /users/123, and the same request can be retried safely.

What is the difference between PUT and PATCH?

PUT creates or replaces the state of a resource at a known URI using a representation defined by the API contract. PATCH applies a set of partial modifications using a patch document. Use PUT when replacement semantics match your contract; use PATCH when the client needs to describe only the changes.

What are safe and idempotent HTTP methods?

Safe methods (GET, HEAD, OPTIONS, TRACE) do not ask the server to change state. Idempotent methods (GET, HEAD, PUT, DELETE, OPTIONS, TRACE) have the same intended effect whether an identical request is made once or multiple times. POST is not idempotent by definition; PATCH can be designed to be idempotent but is not guaranteed to be.

Can GET requests have a request body?

RFC 9110 assigns no generally defined semantics to content in a GET request and warns that some implementations may reject it because of request-smuggling risks. Avoid GET content unless the origin server explicitly supports it and every intermediary in the request path is known to handle it safely. Otherwise, use query parameters or a method whose content semantics match the operation.

What HTTP method should I use to update a resource?

Use PUT when the client is supplying the replacement representation for a known URI. Use PATCH when the client is supplying a patch document that describes partial changes. In both cases, document validation, concurrency controls, and omitted-field behavior in the API contract.

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.
• API7 Enterprise — Enforce method-based routing, rate limiting, and authentication across every API from a single gateway platform.

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.