HTTP Verbs: Your Ultimate Guide
HTTP Verbs Explained: Learn the basics of GET, POST, PUT, DELETE, and more. This article explains how they work, their applications, and their security implications.
A few days ago, my cousin, who is just beginning to explore the fascinating world of computing, asked me a fundamental question: "What are these HTTP verbs that we always talk about, like GET, POST, PUT, and DELETE?" His question inspired me to write this new article, after the last ones on PHP code optimization and the DRY principle. I will now explain HTTP verbs in simple terms, providing concrete examples of each main verb.
What is an HTTP Verb?
When you browse the internet, your browser communicates with servers via HTTP requests. HTTP (Hypertext Transfer Protocol) allows the exchange of information between your browser and servers that host websites. The first version of HTTP only had the verb "GET" to retrieve resources, and other verbs were added later. These verbs are instructions sent by your browser to tell the server what action to perform on a resource, such as a web page, image, or data.
Here's an overview of the main HTTP verbs: GET, POST, PUT, DELETE, and PATCH, as well as the less common HEAD, OPTIONS, TRACE, and CONNECT.
What is an idempotent operation?
Before delving into the details of the verbs, it's important to understand two key HTTP concepts: "safe" and idempotency.
A request is considered "safe" if it doesn't cause any changes to the server's state. For instance, GET requests are 'safe' because they retrieve data without altering it.
Then, an operation is idempotent if it always produces the same result, no matter how many times it is executed. In other words, performing the same request multiple times doesn't further modify the server's state after the first request. This concept is essential for understanding certain verbs, such as GET and PUT, which are idempotent, as opposed to POST, which is not.
With these definitions in mind, let's see how they apply to each HTTP verb and explain why and when to use them.
1. The verb GET: Retrieve information (Idempotent)
When should you use it?
Use GET when you want to retrieve information without making changes to the server. It's the most common method for accessing data, such as displaying a web page or searching a database.
Why use it?
Because GET is safe and idempotent. In fact, all safe methods are idempotent. Sending multiple GET requests does not modify the data, making it ideal for accessing resources.
Example:
Imagine you want to see the list of products on an e-commerce site. You send a GET request to the URL https://example.com/products, and the server returns a list of all available products.
GET /products HTTP/2
Host:example.com2. The POST verb: Send data to the server (Non-idempotent)
When to use it?
Use POST to send data to the server when you want to create a new resource, such as a new user, item, or product, or process information. It is often used in web forms, such as user registration, or to submit non-recurring data.
Reasons to use POST
Since POST is not idempotent, it creates a new resource or changes the server state each time it is used. Unlike verbs such as PUT or DELETE, executing the same POST request multiple times can result in multiple changes, such as creating multiple instances of a resource or making cumulative changes.
Example:
You want to add a new product to the list. You send a POST request to the URL https://example.com/products with the new product's information (e.g., name, price) in the request body.
POST /products HTTP/2
Host: example.com
Content-Type: application/json
{
"name": "New Article",
"price": "29.9"
}3. The verb PUT: Update or replace a resource (Idempotent)
When to use it?
In general, PUT updates or replaces an existing resource on the server or creates a new one if it doesn't yet exist. It's suitable when you know exactly which resource you want to replace or update.
Why use it?
Because PUT is idempotent, the resource's state won't change after the first request if you send the same PUT request multiple times. This is ideal for complete updates or replacements.
Example:
Suppose you want to change the price of an existing product with the ID 123. Send a PUT request to the URL https://example.com/products/123 with the new information.
PUT /products/123 HTTP/2
Host: example.com
Content-Type: application/json
{
"name": "New Article",
"price": 24.99
}4. The verb DELETE: Delete a resource (Idempotent)
What situations does it apply to?
DELETE is used to delete a specific resource on the server. If you want to delete a specific resource, this is the verb to use.
Why is it useful?
DELETE is idempotent, meaning that once a resource is deleted, re-executing the request will have no additional effect.
It is considered idempotent, meaning repeating the same request multiple times always has the same effect. For example, if a resource has already been deleted, a subsequent DELETE request on the same resource will not result in any additional changes.
A successful DELETE request generally returns an HTTP status code of 204 (No Content), indicating that the deletion was performed and there is no content to return.
Example:
You want to delete a product with ID 123 from the list. You send a DELETE request to the URL https://example.com/products/123.
DELETE /products/123 HTTP/2
Host: example.com5. Le verbe PATCH : Modifier partiellement une ressource(Non-idempotent)
When to use it?
Use PATCH when you want to modify a resource partially without replacing it entirely. It is particularly useful for making minor updates to specific data.
When is it relevant?
Note that PATCH is not always idempotent; the effect of a PATCH request can vary depending on how many times it is executed. Therefore, it is ideal for minor adjustments.
Example:
Suppose you just want to change the name of a product without affecting its price. Send a PATCH request to the URL https://example.com/products/123 with only the field to be modified.
PATCH /products/123 HTTP/2
Host: example.com
Content-Type: application/json
{
"name": "Changed Name"
}6. The HEAD Verb: Retrieve response headers (Idempotent)
When should it be used?
Use HEAD when you only want the HTTP response headers, not the body of the content. It's ideal for checking the existence of a resource without downloading it.
Why use it?
Because HEAD is idempotent, each HEAD request returns the same result as long as the resource exists. This allows you to quickly retrieve information about a resource, such as its size or type.
Example
You want to know if a file exists on the server without downloading it. Send a HEAD request to the URL https://example.com/documentation.pdf
HEAD /documentation.pdf HTTP/2
Host: example.com7. The OPTIONS verb: Knowing the supported HTTP methods (Idempotent)
What are its advantages?
The OPTIONS verb is used to query which HTTP methods (GET, POST, etc.) are supported by a specific resource. It is often used for API testing and to configure communication permissions between the client and server.
Why is it useful?
OPTIONS is idempotent and useful when you want to know which actions are permitted without altering the resource.
Example
You want to know what actions you can perform on a resource. Send an OPTIONS request to the URL https://example.com/products/123
OPTIONS /products/123 HTTP/2
Host: example.com8. The verb TRACE: debugging the path taken by the idempotent request.
When should it be used?
TRACE is primarily used to debug and trace the path of an HTTP request through multiple proxies or intermediary servers. It displays the request as seen by the server.
Why use it?
TRACE is idempotent and useful for diagnosing network connection or communication problems.
Example
To see the path taken by a request, send a TRACE request to the URL https://example.com.
TRACE / HTTP/2
Host: example.com9. The verb CONNECT: Establish a connection for a secure tunnel (Idempotent)
When should it be used?
CONNECT is used to establish a secure tunnel through a proxy, often for HTTPS connections. It is primarily used when you use a proxy to access a remote resource.
When is it relevant?
CONNECT is idempotent and allows for secure communications by establishing an encrypted tunnel.
Example
When a secure connection is required through a proxy, a CONNECT request is sent.
CONNECT example.com:443 HTTP/2
Host: example.comHTTP Verb Security
The security of HTTP verbs hinges on proper usage and server-side configurations. Here are some key points:
Secure sensitive data. Use HTTPS to encrypt data transmitted between the client and server, especially for methods that modify data, such as POST and PUT.
Control access: Ensure that only authorized users can perform certain HTTP methods, especially for sensitive operations such as DELETE and PUT.
Prevent attacks: Implement mechanisms to prevent injection attacks and cross-site request forgery (CSRF) by validating input and using security tokens. Although POST requests are more appropriate than GET requests for sensitive actions, they are not inherently more secure. True protection against CSRF attacks relies on mechanisms such as unique CSRF tokens rather than the choice of HTTP method. However, never use GET requests to modify server state because they are designed to retrieve data and can be directly replayed via a URL. To reflect HTTP best practices, POST remains preferable for critical actions.
Conclusion
These HTTP verbs—GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE, and CONNECT—are central to the interaction between your browser and servers.
Each verb plays a specific role in manipulating data and resources on the web. There are also many other HTTP verbs that are more or less standardized, such as LOCK and COPY, which address more specific needs. Mastering these concepts will help you better understand how web applications work, whether you're a user or a developer.
Thanks to these comprehensive explanations, my cousin is now better equipped to navigate the world of computing. I hope this article helps other beginners gain a clearer understanding, too.
