We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Look up the definitions, semantics, idempotency, and safety of HTTP request methods to assist with web development and API design.
This is a locally maintained static reference table, not a live official directory, current policy or complete collection. Records without a named source and update date remain unverified.
Common-method subset checked against IANA on 2026-09-29, not the full registry. Safe/idempotent describe protocol semantics, not security guarantees. LINK/UNLINK are historical RFC 2068 extensions; unregistered WRAPPED was removed. Reference
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
This reference contains 14 configured rows with a method name, display name, short description, and additional note. Search matches text in the displayed data; column headings sort the rows, and column controls can hide fields. It is a static subset, not a live test of a server and not a complete copy of the IANA registry.
Its rows include the core methods GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, and TRACE; PATCH; WebDAV COPY and MOVE; LINK and UNLINK; and WRAPPED. Some stored notes cite older or questionable sources, so use the official registry and current RFCs for protocol semantics.
A safe method is defined so that the client does not request a change to the target resource's state. Idempotency means that multiple identical requests have the same intended effect as one request. Neither term promises identical responses, zero side effects such as logging, or authorization to access a resource.
The IANA registry currently marks GET, HEAD, OPTIONS, and TRACE as safe and idempotent. PUT and DELETE are idempotent but not safe. POST, PATCH, and CONNECT are neither safe nor guaranteed idempotent. Registered extensions have their own entries: COPY, MOVE, LINK, and UNLINK are marked idempotent and not safe. These are method semantics, not a prediction of how a particular application behaves.
GET requests a representation of a target resource. POST asks the target resource to process the request content according to its own semantics; it is not limited to creating a record. PUT creates or replaces the state of the target resource, and is idempotent by definition. PATCH applies a set of partial modifications; the patch format and whether a particular patch is safely repeatable depend on its instructions. DELETE requests removal of the target resource's association, though repeated requests need not return the same status code.
RFC 9110 is the current core HTTP semantics reference and obsoletes RFC 7231. RFC 5789 defines PATCH, and RFC 4918 defines WebDAV extensions such as COPY and MOVE. The table's old notes that cite RFC 7231 should not be treated as the current authority. LINK and UNLINK are registered with historical RFC 2068 references; they are not WebDAV methods. WRAPPED is in the configured table but does not appear as a method in the current IANA registry.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Enter a name such as PATCH or a word from a description. Clear the query if no rows appear, then check spelling.
Read the short description and note together. Sort by a column heading or hide fields to make the comparison easier; these actions change the view, not the stored entry.
Follow a current standards reference for normative meaning. A method appearing in this 14-row selection does not mean every server implements or permits it.
Use the service's documentation and authorization rules. The table does not send OPTIONS requests, inspect routes, or show which methods a particular endpoint accepts.
| Method | Semantic focus | Safe? | Idempotent? |
|---|---|---|---|
| GET | Retrieve a representation | Yes | Yes |
| POST | Process content according to the target resource | No | Not guaranteed |
| PUT | Create or replace target resource state | No | Yes |
| PATCH | Apply partial modifications | No | Not guaranteed |
| DELETE | Remove the target resource's association | No | Yes |
For example, repeating a PUT with the same intended representation should leave the target in the same state. Repeating a PATCH instruction that increments a value can produce another increment. Judge retries from the request's actual semantics and safeguards, not from the method name alone.
Use cases
See how the tool fits into real work and everyday tasks.
Compare candidate methods against the resource operation you intend, then review the full RFC definition and your API's request format.
Use the registry's idempotency property as a starting point when assessing retries after timeouts. Check application side effects and conditional request behavior before enabling automatic retries.
Search for methods such as CONNECT or TRACE as part of a configuration review. Confirm the actual server policy separately; a table entry does not mean a service exposes that method.
Q&A
Find concise answers to common questions and confusing cases.
No. It refers to the intended effect on the target resource. A DELETE may return a success response once and a not-found response later while leaving the resource absent.
The method is not guaranteed to be idempotent. A particular patch document can be repeatable, but another patch, such as an increment instruction, may have a different effect each time.
Not necessarily. A server's response depends on the target, implementation, and policy. This static reference does not query a server.
No. The IANA registry points to historical RFC 2068 for those names. RFC 4918 defines WebDAV methods such as COPY and MOVE.
Those are stored table notes. RFC 9110 supersedes RFC 7231 for current core HTTP semantics, so use RFC 9110 and the current registry for authoritative definitions.
Notes
Review scope, result limitations, and important precautions before use.
This page summarizes a selected set of stored rows; it is not a standards registry mirror or an endpoint capability checker.
Related
Discover related tools, collections, and available API capabilities.