The Hypertext Transfer Protocol (HTTP) is the foundation of data communication on the web. When interacting with web servers, clients (like browsers or apps) use different HTTP methods to request or modify resources. These methods, also called HTTP verbs, indicate the action that the client wants to perform on the server. Let’s explore the most common HTTP methods, their use cases, and how they work.
Table of Contents
Basics
Safe Operation
- A safe operation does not modify the state of the server.
- When you perform a safe operation, you’re simply retrieving information, but you are not changing anything on the server.
- These operations are read-only, meaning they are considered non-destructive.
- No side effects, read-only
Idempotent Operation
- An idempotent operation is one that can be called multiple times with the same outcome as making the call once.
- This means that, regardless of how many times the request is repeated, the state of the resource remains the same after the request is processed.
- The same result, even if the request is repeated
Mapping HTTP Methods to CRUD Operations
| CRUD Operation | HTTP Method |
|---|---|
| Create | POST |
| Read | GET |
| Update | PUT |
| Update (Partial) | PATCH |
| Delete | DELETE |
GET
- The GET method is used to retrieve data from the server.
- It’s a safe and idempotent operation.
Characteristics:
- Purpose: Fetch resources such as web pages, JSON data, or files.
- No Body: GET requests do not have a request body; the parameters (if any) are included in the URL.
- Caching: Browsers often cache GET responses, improving performance.
- Idempotent: Repeated GET requests yield the same result.
- It’s safe
POST
- The POST method is used to send data to the server, typically to create or submit a new resource.
- Unlike GET, POST requests contain a body where the data is passed
- it’s not idempotent
- it’s non-safe
Characteristics:
- Purpose: Submit data to the server, often used in forms, APIs, or when creating new entities.
- Has Body: Contains JSON, XML, or form data in the request body.
- Non-idempotent: Multiple POST requests may create multiple resources or cause different results.
PUT
- The PUT method is used to update or create a resource.
- If the resource exists, it replaces it; if not, it creates a new one.
- It’s idempotent and non-safe.
Characteristics:
- Purpose: Update an existing resource or create a new one.
- Has Body: The updated or new resource is sent in the body of the request.
- Idempotent: Multiple identical PUT requests will result in the same resource state.
DELETE
- The DELETE method requests the removal of a resource from the server.
- It is idempotent, meaning repeating the request will not change the outcome after the resource is deleted.
Characteristics:
- Purpose: Remove a resource.
- Idempotent: After deletion, additional DELETE requests have no further effect.
PATCH
- The PATCH method is used to partially update a resource.
- Unlike PUT, which replaces the entire resource, PATCH modifies only certain fields.
Characteristics:
- Purpose: Apply partial modifications to a resource.
- Has Body: The body contains only the fields to be updated.
- Non-idempotent: Depending on the operation, multiple PATCH requests can result in different outcomes.
OPTIONS
- The OPTIONS method is used to retrieve the communication options for a specific resource.
- This method allows a client to determine the allowed HTTP methods for a particular endpoint.
Characteristics:
- Purpose: Discover what HTTP methods are supported for a resource.
- No Body: Nobody is required in the request, and the response includes allowed methods.
HEAD
- The HEAD method is almost identical to GET, except the server doesn’t return the body in the response.
- It is typically used to check if a resource exists or to inspect headers before downloading a large file.
Characteristics:
- Purpose: Fetch headers without retrieving the full content.
- Idempotent: Repeated HEAD requests yield the same headers.
TRACE
- The TRACE method is used for debugging purposes.
- It echoes back the received request, helping to see how the request is altered as it passes through intermediary proxies.
Characteristics:
- Purpose: Diagnose the request path and alterations.
- Safe: No resource changes are made.
CONNECT
- The CONNECT method is used to establish a network connection to a server, typically for SSL tunnelling.
- This method is often employed when creating a secure connection via HTTPS.
Characteristics:
- Purpose: Establish a tunnel between the client and server.
- Non-idempotent: Multiple requests may open multiple connections.
Comparison
POST VS PUT
- The difference between POST and PUT is that PUT requests are idempotent.
- That is, calling the same PUT request multiple times will always produce the same result.
- In contrast, calling a POST request repeatedly has the side effect of creating the same resource multiple times.
GET vs POST
- In GET parameters can be saved in the browser’s history and also can be bookmarked and cached.
- Put parameters are not archived in the browser history or other web server logs and can’t be bookmarked or cached.
- GET method has a restriction on data length because data is appended in the URL. The maximum length for a URL is 2014 characters, while in POST there are no such restrictions.
- GET, data is visible to everyone, as it is present in the URL, no data is visible in the POST
- In GET allowed data type is ASCII characters, while in POST There is no restriction on data type, and binary data is also allowed.
PUT vs PATCH
- The HTTP PATCH method can be used when a resource needs to be updated. This method is especially useful if a resource is large and the changes being made are small.
- The HTTP PUT method can be used to create a new resource or to replace an existing resource with a new resource. However, the entire resource must be replaced.
- PUT is guaranteed to be idempotent. PATCH is not. Likewise, PUT is considered “safe” in the sense of RFC 2616, while PATCH is not.
Overview
| HTTP Method | Request Body | Idempotent | Safe | Cacheable |
|---|---|---|---|---|
| GET | No | Yes | Yes | Yes |
| HEAD | No | Yes | Yes | Yes |
| OPTIONS | No | Yes | Yes | No |
| TRACE | No | Yes | Yes | No |
| PUT | Yes | Yes | No | No |
| DELETE | No | Yes | No | No |
| POST | Yes | No | No | Conditional* |
| PATCH | Yes | No | No | Conditional* |
| CONNECT | No | No | No | No |
POST and PATCH are cacheable when responses explicitly include freshness information and a matching Content-Location header.
PUT is idempotent while PATCH is not
Applying the same PUT request multiple times results in the same resource state as if the request was made only once. But for PATCH it’s not guaranteed
Example of Non-Idempotent PATCH
If the PATCH operation modifies the resource in a way that accumulates or changes each time it’s applied (e.g., incrementing a value), it is not idempotent. For instance, if you PATCH a resource to increment a counter:
PATCH /counter
{
"operation": "increment"
}Each time you send this request, the counter is incremented, and the resource changes with every request. This makes the PATCH method non-idempotent because repeating the request will lead to different outcomes.
Example of Potentially Idempotent PATCH
In contrast, if you send a PATCH request to update a field to a specific value:
PATCH /user/123
{
"email": "new_email@example.com"
}The outcome is the same whether you send the request once or multiple times. However, because this behaviour depends on the implementation of the patch operation and is not guaranteed, PATCH is considered non-idempotent by default.
CONNECT is non-idempotent
The CONNECT method is considered non-idempotent because its purpose is to establish a network tunnel, typically for HTTPS, between the client and the server. The result of making a CONNECT request multiple times could lead to different states, and repeating the request may have additional effects (such as opening multiple tunnels or connections)
CONNECT is non-safe
The CONNECT method is considered not safe because it has the potential to modify the state of the server or the network infrastructure. Specifically, it initiates a network connection (or tunnel) between the client and another server (often for HTTPS), which has side effects that go beyond mere information retrieval.
Conclusion
HTTP methods define how a client interacts with server resources. Understanding each method’s purpose, idempotency, and safety characteristics is crucial for designing efficient, reliable APIs and applications. By choosing the right HTTP method, developers ensure that their applications behave as expected and follow best practices for web communication.