Tutorial HTTP REST API Web Development Developer Tools

Free HTTP Methods Cheat Sheet Online — Interactive REST API Reference

· 22 min read

HTTP methods are the verbs of the web. Every request your browser, mobile app, or API client sends uses one of these methods to tell the server what action to perform. Should it retrieve data? Create a new record? Update an existing one? Remove it entirely? Understanding the semantics of each method is fundamental to building robust REST APIs, debugging network issues, and writing correct client code. Yet many developers still confuse PUT vs PATCH, misuse POST for updates, or treat GET requests as if they were side-effect free when they are not.

Our free interactive HTTP methods cheat sheet gives you an at-a-glance reference for all nine standard HTTP methods. It covers safety, idempotency, typical status codes, real-world examples, and common mistakes. Whether you are designing a new API, reviewing code in a pull request, or studying for a system design interview, this cheat sheet saves you from memorizing RFC 7231. Everything runs in your browser, so your data never leaves your machine. You can search by keyword, filter by category, and copy code snippets instantly. Bookmark the interactive tool and keep it open during your next API design session.

Table of Contents

  1. What Are HTTP Methods?
  2. Safe vs Unsafe Methods
  3. Idempotent vs Non-Idempotent Methods
  4. GET — The Retrieval Method
  5. POST — The Creation Method
  6. PUT vs PATCH — The Complete Comparison
  7. DELETE — The Removal Method
  8. HEAD — Headers Only
  9. OPTIONS — Capability Discovery
  10. TRACE — Echo Test
  11. CONNECT — Tunnel Establishment
  12. HTTP Method Comparison Table
  13. RESTful URL Design Best Practices
  14. Common HTTP Status Codes by Method
  15. When to Use Which Method?
  16. HTTP Methods in HTTP/2 and HTTP/3
  17. Summary / TL;DR
  18. Try the Tool
  19. Related Articles

What Are HTTP Methods?

HTTP methods, also called HTTP verbs, define the action a client wants to perform on a resource identified by a URL. They were introduced in the earliest versions of the Hypertext Transfer Protocol and formalized in RFC 7231, which remains the primary reference for HTTP/1.1 semantics today. When a client sends a request, the method appears on the request line before the resource path and HTTP version:

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

The server reads this method and decides how to process the request. A GET request should retrieve the user. A DELETE request to the same path should remove the user. The method is what gives the request its meaning. Without methods, HTTP would be a simple file retrieval protocol. With methods, it becomes a general-purpose application protocol capable of powering everything from static websites to complex distributed systems.

HTTP/1.1, standardized in 1997 and refined in RFC 7231 in 2014, defines eight primary methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, and TRACE. PATCH was added later in RFC 5789 to address the need for partial updates. These nine methods form the complete set that every web developer should understand. HTTP/2 and HTTP/3 preserve the same method semantics; they only change how requests are transported at the wire level.

The concept of methods maps naturally to the Create, Read, Update, Delete (CRUD) pattern that underlies most database and API designs. However, the mapping is not one-to-one, and treating it as such leads to common design errors. POST, for example, is far more flexible than simple creation. PUT can create as well as replace. Understanding the semantic intent of each method, rather than forcing a rigid CRUD mapping, leads to better API designs.

If you are also working with HTTP responses, our HTTP Status Codes Reference Guide pairs perfectly with this article for a complete picture of request-response semantics.

Safe vs Unsafe Methods

A safe method is one that does not alter the state of the server. In other words, the client does not request, and the server does not perform, any side effects beyond what is necessary to produce the response. Safe methods are read-only operations. They can be cached, prefetched by browsers, and triggered by automated tools without risk of damaging data.

The safe methods defined by RFC 7231 are GET, HEAD, OPTIONS, and TRACE. Calling any of these methods should not modify resources, create new records, or delete existing ones. This does not mean the server cannot log the request or update analytics counters. It means the resource state visible to the client must remain unchanged.

Unsafe methods are POST, PUT, PATCH, and DELETE. These methods are expected to change server state. A POST creates a resource. A PUT replaces one. A PATCH modifies one. A DELETE removes one. Because they have side effects, unsafe methods require more care. Browsers warn users when resubmitting a POST form. APIs require authentication and authorization checks before allowing unsafe operations. Caching proxies refuse to cache unsafe requests by default.

A common mistake is implementing state-changing logic behind a GET endpoint. For example, a logout link that sends GET /logout and invalidates the session. This violates the safety guarantee. Web crawlers, prefetchers, and browser plugins may follow GET links automatically, causing accidental logouts or worse. Always use POST for actions that change state, even if no resource is created.

Another subtle issue is that safety is a semantic contract, not a technical guarantee. A poorly implemented GET handler could still write to a database. The method label tells intermediaries and clients what to expect, but the actual behavior depends on the server implementation. Good API design honors these contracts because they enable caching, retry logic, and predictable client behavior.

Idempotent vs Non-Idempotent Methods

Idempotency is one of the most important yet misunderstood concepts in HTTP. An idempotent method produces the same server state regardless of how many times it is executed with the same request payload. If you send an idempotent request once, twice, or a hundred times, the end result is identical. This property is invaluable for building reliable distributed systems where network timeouts and retries are inevitable.

The idempotent methods are GET, PUT, DELETE, HEAD, OPTIONS, and TRACE. POST is explicitly non-idempotent. PATCH is idempotent only if the patch document is applied in an idempotent way; because PATCH semantics depend on the patch format, RFC 5789 does not guarantee idempotency for PATCH in general, though in practice most PATCH implementations are idempotent.

Consider PUT as the classic idempotent example. If you send PUT /users/123 with a JSON payload representing a user, the first request creates or replaces the user. The second request with the same payload replaces the user with the same data, leaving the server in the same state. The response may differ — the first might return 201 Created, the second 200 OK or 204 No Content — but the resource state is unchanged after the second call.

DELETE is also idempotent. Deleting a resource that already exists returns 200 OK or 204 No Content. Deleting it again returns 404 Not Found or 204 No Content, depending on implementation. Either way, the resource is gone after the first call, and subsequent calls do not bring it back or cause additional harm.

POST is not idempotent because each call typically creates a new resource. Submitting a payment twice charges the customer twice. Submitting a comment twice creates duplicate comments. This is why browsers warn users about resubmitting forms and why APIs often require idempotency keys for POST requests that must not be duplicated.

Idempotency enables safe retries. If a client sends a PUT request and the connection drops before the response arrives, the client cannot know whether the server processed the request. Because PUT is idempotent, the client can safely retry without risk of corruption. With POST, the client must query the server state or use an idempotency key before retrying.

GET — The Retrieval Method

GET is the most widely used HTTP method. It requests a representation of a specified resource. Every time you open a web page, load an image, or fetch JSON data from an API, you are using GET. Its semantics are simple: retrieve the resource at the given URL and return it in the response body.

GET requests should never have side effects. They should not modify server state, create resources, or delete data. This safety guarantee allows browsers to prefetch GET links, search engines to crawl them, and CDNs to cache them aggressively. Violating this expectation breaks the web.

A typical GET request looks like this:

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

The server responds with the resource representation and an appropriate status code:

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

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

GET requests can include query parameters in the URL to filter, sort, or paginate results. These parameters are part of the cache key, which means two GET requests with different query strings are treated as separate cache entries.

GET /users?role=admin&sort=name&page=2 HTTP/1.1
Host: api.example.com

Common mistakes with GET include placing sensitive data in query parameters (which may be logged in server access logs and browser history), using GET for actions that modify state, and building URLs that exceed length limits when encoding complex filters. For large filter payloads, consider using POST with a request body, though this sacrifices cacheability.

GET is both safe and idempotent. You can retry a failed GET request without concern. You can bookmark it, share it, and cache it. These properties make GET the workhorse of the web and the default choice for any read operation.

POST — The Creation Method

POST submits an entity to the specified resource, often causing a change in state or side effects on the server. While POST is commonly used to create new resources, its semantics are broader than simple creation. POST can trigger processing, submit form data, initiate workflows, or perform any action that does not fit the narrow semantics of PUT, PATCH, or DELETE.

When POST creates a resource, the server typically assigns the new resource URI and returns it in the Location header with a 201 Created status code.

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

{
  "name": "Bob Smith",
  "email": "bob@example.com"
}

Server response:

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

{
  "id": 456,
  "name": "Bob Smith",
  "email": "bob@example.com"
}

The Location header tells the client where to find the newly created resource. This is a critical part of the HTTP contract. Clients can follow the Location header with a GET request to retrieve the resource immediately after creation.

POST is neither safe nor idempotent. Sending the same POST request twice usually creates two resources or triggers the action twice. This is why payment processors, booking systems, and form submissions require protection against duplicate submissions. Common techniques include idempotency keys (unique tokens sent in a header that the server checks before processing), CSRF tokens, and redirect-after-post patterns.

POST is also used for operations that do not create resources. Search endpoints with complex query payloads, batch operations, and RPC-style API calls often use POST because the operation does not fit the PUT or PATCH semantics.

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

{
  "query": "laptops",
  "filters": {
    "price_min": 500,
    "price_max": 1500,
    "brand": ["Apple", "Dell"]
  },
  "sort": "price_asc"
}

Common mistakes with POST include forgetting to return the Location header after creation, using POST when PUT would be more appropriate (when the client knows the target URI), and failing to handle duplicate submissions in state-changing operations.

PUT vs PATCH — The Complete Comparison

The difference between PUT and PATCH is one of the most frequently asked questions in REST API design. Both methods update resources, but they do so with fundamentally different semantics. Choosing the wrong method leads to data loss, unexpected behavior, and frustrated API consumers.

PUT Replaces the Entire Resource

PUT requests that the enclosed entity be stored under the supplied Request-URI. If the resource already exists, it is completely replaced by the request payload. If it does not exist, the server may create it, depending on implementation. The key word is replace. A PUT request must include the full representation of the resource. Any fields omitted from the payload may be reset to null or default values.

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

{
  "id": 123,
  "name": "Alice Johnson",
  "email": "alice.new@example.com",
  "role": "admin"
}

If the original user had a phone field and the PUT payload does not include it, the server may remove the phone number. This is the correct behavior per RFC 7231, though some APIs deviate from the standard and merge PUT payloads instead. Deviating from the standard creates confusion, so it is better to use PATCH for partial updates.

PUT is idempotent. Sending the same PUT request twice results in the same resource state. The first request might create the resource (201 Created), while the second updates it in place (200 OK or 204 No Content). The end state is identical.

PATCH Applies Partial Modifications

PATCH requests that a set of changes described in the request entity be applied to the resource. Unlike PUT, PATCH does not replace the entire resource. It modifies only the fields specified in the patch document. This makes PATCH ideal for updating a subset of resource properties without affecting others.

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

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

In this example, only the email address changes. The name, role, phone, and all other fields remain untouched. This is the primary advantage of PATCH: it reduces payload size and prevents accidental overwrites of fields the client did not intend to modify.

PATCH is idempotent when the patch document is applied in an idempotent way. If the patch sets a field to a specific value, applying it twice produces the same result. However, RFC 5789 does not mandate idempotency for PATCH because some patch formats (such as counters or append operations) may not be idempotent. In practice, most JSON-based PATCH implementations are idempotent.

PUT vs PATCH Comparison Table

Aspect PUT PATCH
Semantics Full replacement Partial modification
Payload Complete resource representation Partial fields or patch document
Omitted fields May be reset to null or defaults Unchanged
Idempotent Yes Usually yes (depends on patch format)
Safe No No
Status codes 200, 201, 204 200, 204
When to use Client has complete new state Client wants to change specific fields
Resource creation Yes, if URI is known No (updates existing only)

Practical Examples

Scenario: Updating a user profile

If the user submits a complete profile form with all fields, use PUT:

PUT /users/123 HTTP/1.1
Content-Type: application/json

{
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "phone": "+1-555-1234",
  "address": {
    "street": "123 Main St",
    "city": "Springfield",
    "zip": "12345"
  }
}

If the user only updates their email from a quick-edit field, use PATCH:

PATCH /users/123 HTTP/1.1
Content-Type: application/json

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

Scenario: JSON Patch format (RFC 6902)

For APIs that require explicit patch semantics, JSON Patch provides a standardized format:

PATCH /users/123 HTTP/1.1
Content-Type: application/json-patch+json

[
  { "op": "replace", "path": "/email", "value": "alice.new@example.com" },
  { "op": "add", "path": "/tags/-", "value": "premium" },
  { "op": "remove", "path": "/phone" }
]

JSON Patch is verbose but unambiguous. It supports add, remove, replace, move, copy, and test operations. If your API needs fine-grained change tracking or audit logs, JSON Patch is worth considering over simple merge patches.

Common mistakes with PUT and PATCH include using PUT for partial updates (which overwrites unspecified fields), using PATCH without proper content-type negotiation, and failing to validate that the patch document actually changes the resource before returning 200 OK.

DELETE — The Removal Method

DELETE requests that the origin server remove the association between the target resource and its current functionality. In plain terms, DELETE removes the resource. After a successful DELETE, subsequent GET requests to the same URI should return 404 Not Found or 410 Gone.

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

Server response:

HTTP/1.1 204 No Content

DELETE is idempotent but not safe. Deleting a resource twice has the same end state as deleting it once: the resource no longer exists. The first request might return 200 OK or 204 No Content. The second might return 404 Not Found because the resource is already gone. Both are acceptable responses.

A design decision every API team faces is whether to perform hard deletes or soft deletes. A hard delete permanently removes the record from the database. A soft delete sets a flag (such as deleted_at) that hides the resource from normal queries but preserves the data for recovery or audit purposes.

Hard deletes are simpler and consume less storage. They are appropriate for temporary data, logs, and resources where recovery is not a business requirement. Soft deletes are safer and support undo functionality. They are common in content management systems, e-commerce platforms, and any domain where accidental deletion has significant consequences.

From the client's perspective, the HTTP semantics are identical regardless of the backend implementation. A successful DELETE means the resource is no longer accessible through its URI. Whether the data is physically erased or merely hidden is an implementation detail.

Common mistakes with DELETE include requiring a request body (some servers and proxies reject DELETE with a body), failing to handle cascading deletes in related resources, and returning 200 OK with a response body when 204 No Content is more appropriate for simple deletions.

HEAD is identical to GET except that the server must not return a message body in the response. It retrieves the headers that would be returned by a GET request to the same resource. HEAD is useful for checking resource metadata without downloading the entire payload.

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

Server response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 187
Last-Modified: Mon, 11 May 2026 14:30:00 GMT
ETag: "abc123"

Notice there is no response body. The client learns that the resource exists, what format it is in, how large it is, and when it was last modified, all without transferring the actual data.

Common use cases for HEAD include:

  • Checking whether a resource exists before downloading it
  • Verifying cache freshness using Last-Modified or ETag headers
  • Determining the content type or size before deciding how to process the resource
  • Testing link validity in crawlers and monitoring tools

HEAD is safe and idempotent. Because it does not return a body, it is faster than GET for metadata checks. However, the server must generate the same headers it would for GET, which may still require database queries or expensive computations. Some APIs optimize HEAD by skipping body serialization but still perform the underlying lookup.

OPTIONS — Capability Discovery

The OPTIONS method requests information about the communication options available for the target resource. It tells the client which HTTP methods are supported, what headers are allowed, and whether credentials may be included in cross-origin requests.

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

Server response:

HTTP/1.1 204 No Content
Allow: GET, HEAD, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

The Allow header lists the methods supported by the resource. This is valuable for API discovery and for building generic HTTP clients that adapt to resource capabilities.

OPTIONS is most famous for its role in Cross-Origin Resource Sharing (CORS). When a browser makes a cross-origin request with methods other than GET, HEAD, or POST, or with custom headers, it first sends an OPTIONS preflight request to ask the server for permission.

OPTIONS /api/data HTTP/1.1
Host: api.example.com
Origin: https://frontend.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization

The server responds with CORS headers indicating whether the requested method and headers are permitted. If the preflight succeeds, the browser proceeds with the actual request. If it fails, the browser blocks the request and reports a CORS error.

OPTIONS is safe and idempotent. It should not have side effects. Some APIs return a response body with documentation or schema information, though this is not required by the RFC. The primary purpose is header-based capability discovery.

TRACE — Echo Test

TRACE performs a message loop-back test along the path to the target resource. The server echoes back the request message it received, including any headers added by intermediaries. TRACE is primarily a diagnostic tool for debugging network infrastructure.

TRACE /users/123 HTTP/1.1
Host: api.example.com
X-Custom-Header: test-value

Server response:

HTTP/1.1 200 OK
Content-Type: message/http

TRACE /users/123 HTTP/1.1
Host: api.example.com
X-Custom-Header: test-value
Via: 1.1 proxy.example.com

TRACE is safe and idempotent. However, it poses a significant security risk known as Cross-Site Tracing (XST). If an attacker can inject malicious scripts into a page and the server supports TRACE, the script can send a TRACE request and read sensitive headers (such as cookies) that are normally inaccessible through JavaScript. For this reason, most production servers disable TRACE entirely.

Modern APIs and web applications rarely use TRACE. Load balancers, proxies, and security scanners often block it by default. If you need to debug request routing, tools like curl -v or proxy inspection provide the same information without the security exposure.

CONNECT — Tunnel Establishment

CONNECT establishes a tunnel to the server identified by the target resource. It is primarily used with proxies to create end-to-end encrypted connections, most commonly for HTTPS traffic through an HTTP proxy.

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

When a client needs to access an HTTPS server through an HTTP proxy, it sends CONNECT to ask the proxy to open a TCP tunnel to the destination. After the proxy responds with 200 Connection Established, the client and server perform the TLS handshake through the tunnel, and all subsequent traffic is encrypted end-to-end. The proxy sees only encrypted bytes and cannot read the content.

HTTP/1.1 200 Connection Established

CONNECT is not safe and not idempotent in the general case because it changes the connection state. However, for the specific use case of proxy tunneling, repeated CONNECT requests to the same destination produce the same tunnel behavior.

Most application developers never implement CONNECT handlers directly. It is handled by web servers, proxies, and networking libraries. Understanding CONNECT is useful for debugging proxy configurations, analyzing network traffic, and implementing custom tunneling solutions.

HTTP Method Comparison Table

The following table summarizes all nine HTTP methods side by side for quick reference:

Method Safe Idempotent CRUD Mapping Body in Request Body in Response Primary Use Case
GET Yes Yes Read No Yes Retrieve a resource
POST No No Create Yes Yes Create resource or trigger action
PUT No Yes Update/Replace Yes Optional Full resource replacement
PATCH No Usually Partial Update Yes Optional Partial resource modification
DELETE No Yes Delete No Optional Remove a resource
HEAD Yes Yes Read (metadata) No No Retrieve headers only
OPTIONS Yes Yes Discover No Optional Capability discovery / CORS preflight
TRACE Yes Yes Debug No Yes Echo request for diagnostics
CONNECT No No Tunnel No No Establish proxy tunnel

RESTful URL Design Best Practices

HTTP methods gain their full power when combined with well-designed URLs. A RESTful API uses URLs to identify resources and methods to specify actions. Following these conventions makes your API predictable, discoverable, and easy to consume.

Use plural nouns for collections. A collection of users is /users, not /user or /getUsers. The method provides the verb; the URL should be a noun.

GET /users          # List all users
GET /users/123      # Retrieve user 123
POST /users         # Create a new user
PUT /users/123      # Replace user 123
PATCH /users/123    # Partially update user 123
DELETE /users/123   # Delete user 123

Nest resources for relationships. When one resource belongs to another, nest the child under the parent.

GET /users/123/orders       # List orders for user 123
GET /users/123/orders/456   # Retrieve specific order
POST /users/123/orders      # Create an order for user 123

Avoid deep nesting beyond two or three levels. Deeply nested URLs become unwieldy and suggest that your resource model needs refactoring.

Use query parameters for filtering, sorting, and pagination. Do not create new URLs for every filter combination.

GET /users?role=admin&sort=-created_at&page=3&limit=20

Version your API in the URL or header. URL versioning is more explicit and easier to debug.

GET /v1/users/123
GET /v2/users/123

Avoid action names in URLs. The method defines the action. URLs should name resources, not operations.

# Bad
POST /users/123/updateEmail
POST /createUser

# Good
PATCH /users/123
POST /users

Use hyphens, not underscores or camelCase, in URLs. Hyphens are more readable and SEO-friendly.

# Good
GET /order-items/456

# Bad
GET /order_items/456
GET /orderItems/456

For more on URL design, try our URL Toolkit and URL Parser tools.

Common HTTP Status Codes by Method

Each HTTP method has a set of status codes that clients expect to see in normal and error conditions. Returning the wrong code confuses clients and breaks standard libraries.

GET and HEAD

  • 200 OK — The resource was found and returned.
  • 304 Not Modified — The cached version is still valid.
  • 400 Bad Request — The query parameters are malformed.
  • 401 Unauthorized — Authentication is required.
  • 403 Forbidden — The client lacks permission.
  • 404 Not Found — The resource does not exist.
  • 500 Internal Server Error — The server encountered an unexpected condition.

POST

  • 201 Created — The resource was created successfully. Include a Location header.
  • 202 Accepted — The request was accepted for asynchronous processing.
  • 204 No Content — The action succeeded but there is no body to return.
  • 400 Bad Request — The request body is invalid.
  • 409 Conflict — The request conflicts with the current state (e.g., duplicate email).
  • 422 Unprocessable Entity — The syntax was correct but the semantics were invalid.

PUT

  • 200 OK — The resource was updated and the updated representation is returned.
  • 201 Created — A new resource was created at the specified URI.
  • 204 No Content — The update succeeded with no body returned.
  • 400 Bad Request — The payload is malformed.
  • 404 Not Found — The resource does not exist and the server does not allow creation.
  • 409 Conflict — The update conflicts with another change.

PATCH

  • 200 OK — The patch was applied and the updated representation is returned.
  • 204 No Content — The patch was applied successfully.
  • 400 Bad Request — The patch document is malformed.
  • 404 Not Found — The resource to patch does not exist.
  • 409 Conflict — The patch cannot be applied to the current resource state.
  • 415 Unsupported Media Type — The patch format is not supported.

DELETE

  • 200 OK — The resource was deleted and a status message is returned.
  • 202 Accepted — The deletion was accepted for asynchronous processing.
  • 204 No Content — The resource was deleted successfully.
  • 404 Not Found — The resource did not exist.

For a deeper dive into status codes, see our HTTP Status Codes Reference Guide and try the HTTP Status Code Lookup tool.

When to Use Which Method?

Choosing the right method can be simplified with a decision flowchart. Follow these questions when designing an API endpoint:

  1. Are you retrieving data? Use GET. If you only need metadata, use HEAD.
  2. Are you creating a resource and the server assigns the ID? Use POST.
  3. Are you creating or replacing a resource and the client knows the exact URI? Use PUT.
  4. Are you updating only some fields of an existing resource? Use PATCH.
  5. Are you removing a resource? Use DELETE.
  6. Are you checking what methods or CORS headers are supported? Use OPTIONS.
  7. Are you establishing a proxy tunnel for TLS? Use CONNECT.
  8. Are you debugging request routing through proxies? Use TRACE (with caution).

When in doubt, prefer the method with the narrowest semantics that fits your use case. Overloading POST to handle every operation may seem convenient, but it sacrifices cacheability, idempotency, and the ability of generic HTTP tools to understand your API.

HTTP Methods in HTTP/2 and HTTP/3

HTTP/2, standardized in RFC 7540, and HTTP/3, built on QUIC and standardized in RFC 9114, do not change the semantics of HTTP methods. GET still retrieves, POST still creates, PUT still replaces. What changes is how requests are transported.

HTTP/2 introduces multiplexing, header compression (HPACK), and server push. Multiple requests and responses can share a single TCP connection without head-of-line blocking. Methods benefit from this because a page that issues dozens of GET requests for assets loads much faster.

HTTP/3 replaces TCP with QUIC, a transport protocol built on UDP. It eliminates the TCP handshake latency and improves performance on unreliable networks. Methods remain unchanged, but the reduced latency makes idempotent retries even more effective because failed requests can be retried faster.

One practical implication is that HTTP/2 and HTTP/3 enforce stricter rules about method usage in certain contexts. For example, server push responses must be cacheable and safe, which means only GET and HEAD responses are typically pushed. CONNECT semantics are also affected because HTTP/2 and HTTP/3 handle TLS differently at the transport layer.

For most API designers, the transition to HTTP/2 and HTTP/3 is transparent. Focus on correct method semantics, and the transport layer will optimize delivery automatically.

Summary / TL;DR

HTTP methods are the foundation of REST API design. Each method carries specific semantics that determine whether a request is safe, idempotent, cacheable, and appropriate for a given operation.

  • GET retrieves resources. It is safe and idempotent. Use it for all read operations.
  • POST creates resources or triggers actions. It is neither safe nor idempotent. Return 201 Created with a Location header on success.
  • PUT fully replaces a resource. It is idempotent but not safe. The client must send the complete representation.
  • PATCH partially updates a resource. It is usually idempotent but not safe. Use it when only specific fields change.
  • DELETE removes a resource. It is idempotent but not safe. Consider soft deletes for recoverability.
  • HEAD retrieves headers only. It is safe and idempotent. Use it for metadata checks.
  • OPTIONS discovers capabilities. It is safe and idempotent. Browsers use it for CORS preflight.
  • TRACE echoes the request. It is safe and idempotent but rarely used due to XST security risks.
  • CONNECT establishes tunnels. It is used primarily for HTTPS proxying.

Choosing the right method makes your API predictable, enables caching and safe retries, and allows generic HTTP clients to interact with your service correctly. When in doubt, consult the cheat sheet.

Try the Interactive HTTP Methods Cheat Sheet

Memorizing every detail of RFC 7231 is not necessary. Our free interactive HTTP Methods Cheat Sheet gives you instant access to all nine methods with safety and idempotency flags, typical status codes, real-world examples, and common pitfalls. It runs entirely in your browser with no server-side processing.

Try the Interactive HTTP Methods Cheat Sheet

Search, compare, and copy method references instantly. Open the tool →

Expand your developer toolkit with these related references:

Found this useful? Check out our free developer tools or browse more articles.