What Are HTTP Methods? Operations on Web Resources
The Hypertext Transfer Protocol (HTTP) is an application-layer protocol used by web browsers (clients) and web servers to exchange messages. It includes . Method names are case-sensitive tokens recorded by IANA. They tell the server what the client wants to do with a specific resource, such as a webpage, an image, a video, or data from a database.
When a browser sends a request to a server, the method is one of its first elements and defines the operation semantics. Asking for a webpage has a different purpose from asking the server to store a user's new profile picture. Separating operations into methods helps servers and APIs use HTTP semantics consistently. The common methods below are compared by purpose and properties.
Primary HTTP Methods
Numerous HTTP methods exist, but a few handle most common web interactions. Their properties help explain how web services work.
A method is interpreted together with the target URI, request fields, content, and resource semantics, which determine the response and status code.
GET
The method requests a representation of a specified resource. It is widely used on the web. Typing a URL, following a hyperlink, and loading images or stylesheets cause requests. The purpose of a request is to retrieve data from the server.
Properties of GET
- Safe: requests are considered . Making a request does not ask for a data change, a new resource, or another operation that modifies the resource. A search engine can crawl the web and send many requests because the method semantics do not call for modifying indexed sites.
- Idempotent: requests are . Making the same request once or multiple times should have the same effect. Requesting the homepage of a news site five times in a row returns the same homepage each time, barring dynamic content updates, and repeated requests have the same intended effect on server state.
- Data in URL: A request often places search parameters in the URL, for example
/search?query=http. URI values can appear in server logs, browser history, and monitoring tools. Content in a request has no generally defined semantics, so a client should not send it without an agreement with the server. For sensitive data, a client can consider content when caching is not needed; moving data into content does not provide confidentiality by itself. - Cacheable: Responses to can be stored by browsers, proxy servers, and CDNs (Content Delivery Networks) when cache rules permit it. Later requests for the same resource can then use the cache instead of contacting the origin server.
Example Scenario
A browser requests a user's profile page.
Request
GET /users/profile/123 HTTP/1.1
Host: api.example.com
Accept: application/jsonResponse
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 104
{
"userId": 123,
"username": "AlexSmith",
"email": "alex.smith@example.com"
}POST
The method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server. It is most commonly used for creating a new resource that is subordinate to another resource. For example, submitting a comment on a blog post creates a new comment resource under that specific post.
Properties of POST
- Not Safe: is not a safe method. It can ask the target resource to create or modify data, depending on that resource's semantics. Submitting a user registration form can change the server's database.
- Not idempotent by method definition: The specification does not classify as idempotent. Repeating the same request can create multiple resources. Sending an order form twice can therefore create two orders, although a service can implement its own duplicate-detection mechanism.
- Data in Body: Data submitted in a request is placed in the message content rather than the URI. Putting data in content is not encryption and does not provide confidentiality, but it supports large payloads such as file uploads.
- Limited cacheability: A response can be reused from a cache only with explicit freshness, such as
Cache-ControlorExpires, and aContent-Locationequal to the request URI.
Example Scenario
A user signs up for a new account.
Request
POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 56
{
"username": "JaneDoe",
"password": "supersecret"
}Response
HTTP/1.1 201 Created
Location: /users/456
{
"userId": 456,
"message": "User created successfully"
}PUT
The method is used to replace the entire representation of a target resource with the request payload. If the target resource does not exist, the server may create it. The key difference from is that is directed at a specific, known URL, whereas sends data to a URL that processes it (e.g., /users) and the server decides the URL of the new resource.
Properties of PUT
- Not Safe: Like , modifies state on the server.
- Idempotent: This is the defining characteristic of . Sending the same request multiple times will have the exact same result as sending it once. A request that updates a user's name to "Jane Smith" changes it on the first request; later requests set the same value again, resulting in the same final state on the server.
- Data in Body: The payload, which represents the complete updated resource, is sent in the body of the message.
Example Scenario
Updating a user's email address.
Request
PUT /users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
{
"username": "AlexSmith",
"email": "alex.new.email@example.com"
}Response
HTTP/1.1 200 OK
{
"userId": 123,
"username": "AlexSmith",
"email": "alex.new.email@example.com"
}DELETE
The method requests removal of the target resource's association with its current function on the server. The representation or stored data may be deleted, archived, or retained depending on the implementation.
Properties of DELETE
- Not Safe: It changes the state of the target resource and its mapping on the server.
- Idempotent: is idempotent. The first request to delete
/users/123will delete the user. A second request to delete the same resource will result in the same state: the user with ID 123 does not exist. The server might respond with a the first time and a the second time, but the end state of the resource itself is identical (it's gone).
Example Scenario
Deleting a user account.
Request
DELETE /users/123 HTTP/1.1
Host: api.example.comResponse
HTTP/1.1 204 No ContentHEAD
The method requests response fields like those for without response content. A server can omit fields whose values are determined only while generating the content. The method is useful for checking metadata such as Content-Type, Content-Length, or Last-Modified without downloading the complete file.
Properties of HEAD
- Safe: Yes, it does not alter server state.
- Idempotent: Yes, for the same reasons as .
Example Scenario
Checking the size of a large file before deciding to download it.
Request
HEAD /downloads/large-file.zip HTTP/1.1
Host: storage.example.comResponse
HTTP/1.1 200 OK
Content-Type: application/zip
Content-Length: 104857600
Last-Modified: Fri, 15 Jun 2025 10:00:00 GMTSecondary Methods: The Specialized Tools
Beyond the primary methods, HTTP defines several others with more specialized purposes, often used in API development or for network diagnostics.
- OPTIONS
- The method is used to describe the communication options for the target resource. A client can use to find out which HTTP methods a server supports for a specific URL. It is an important part of the (Cross-Origin Resource Sharing) mechanism. Before a browser sends a complex cross-origin request (like a or to a different domain), it first sends an request (a "pre-flight" request) to ask the server for permission.
- PATCH
- The method is used to apply partial modifications to a resource. While replaces the entire resource, provides a set of instructions on how to change it. For example, a request might just contain the instruction to change a user's email address, leaving the username and other fields untouched. This can be more efficient than sending the entire resource representation back and forth. is not safe and, importantly, is not necessarily idempotent. For example, a patch instruction like "add 10 to the user's score" would produce a different result if sent twice.
- CONNECT
- The method establishes a tunnel to the server identified by the target resource. It is commonly used to create an connection through an proxy. The proxy can connect to the destination host and relay bytes in both directions; HTTPS content remains unreadable to it unless TLS terminates there.
- TRACE
- The method performs a message loop-back test along the path to the target resource. It allows a client to see what (if any) changes or additions have been made by intermediate servers (like proxies) to the request message. It is a debugging and diagnostic tool. Due to potential security risks (Cross-Site Tracing), it is often disabled on production web servers.
Understanding Safety vs. Idempotency
Safety and idempotency describe different properties: safety concerns the requested operation, while idempotency concerns its intended effect when the request is repeated.
Safety
A method is safe when its semantics specify a read-only operation. The client does not request a change to the resource state. Logs, counters, and other implementation actions can still change on the server, but they are not part of the requested semantics.
Safe Methods: , , ,
Unsafe Methods: , , ,
Idempotency
A method is idempotent if sending an identical request multiple times has the same intended effect on the server as sending it once. The resource state should be the same after the first and later requests, although responses can differ. For example, repeatedly setting an audio volume parameter to 15 leaves the parameter at 15.
Idempotent Methods: , , , , ,
Non-Idempotent Methods: , (generally)
Key distinction: Safety describes the read-only intent of an operation. Idempotency describes the same target state after repeated execution. All safe methods are also idempotent by definition. and are idempotent because they lead to a specified state, while they remain unsafe because they change that state.