The request method is how your web browser or app talks to a server. It tells the server what you want to do (like get information or update something). Think of it as the language they use to communicate.
HTTP serves as this common language. When you make a request, it’s like asking for something specific on a website (like a photo or a page). The request method helps you specify what you want to do with that thing (like get it, delete it, or update it).
First, let's see the list of request methods and then explain each of them separately:
The method names are case-sensitive and by convention, standardized methods are defined in all-uppercase US-ASCII letters. In this list, I specified whether each of the methods can contain a Body or not and whether it is idempotent.
Idempotent means that any number of repeated, identical requests will leave the resource in the same state. It is an important point to consider when you're trying to design and write your APIs.
CONNECT: Starts two-way communications between client and server. Can be used to open a tunnel. Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS.
CONNECT uses a special form of request-target which is unique to this method and contains host and port. There is no default port; a client MUST send the port number even if the CONNECT request is a complete URI. for example:
CONNECT server.example.com:80 HTTP/1.1
Specifying HTTP versions might help since CONNECT the request/response behavior based on the HTTP version, also server MUST reject any requests that are sending empty ports usually with Bad Request(400).
OPTIONS: The OPTIONS method is like asking a server, “What can you do?” It helps clients (like web browsers) figure out the communication options available for a specific thing (a resource) on the server.
If the request is just an asterisk (“*”), it’s a general check to see if the server is working properly (like a “ping”).
- If it’s not an asterisk, it’s about the options available for that specific thing.
- The server responds with info about what it can handle (like features or extensions), but there’s no standard way to describe it—kind of like asking someone, “What can you cook?” without specific details. Also, the response
isn’tstored in a cache.
So, OPTIONS helps clients understand what’s possible, without actually doing anything to the resource.
GET: GET is the primary mechanism of getting data from the server and is the place where most of the performance is considered. GET API responses are cacheable as a result of idempotency, now we better understand why keeping idempotency is very important.
Post: This method is for processing a resource enclosed in the request and can be one of the following usages:
- Sending a block of data like an HTML form for processing those data, a good example is for the
Loginpage. - Creating a
newresource that is not identified by the server (say it does not exist in the database). - Appending to an existing resource.
- For sending a message or item to an inbox or mailing list.
Usually, after a new resource is created the response status code should be 201 (Created) along with a Location to point to the new resource.
PUT: The PUT method is used to create or update a resource on the server with the data you send in your request. If the PUT request is successful, you should be able to retrieve the updated resource using a GET request and get the same data you sent. However, there's no guarantee that the resource will remain unchanged because other users or the server might modify it. A successful PUT response means your request was processed as intended by the server at that moment.
If the resource you're targeting doesn't exist and the PUT request successfully creates it, the server must notify you with a 201 (Created) response. If the resource already exists and the PUT request successfully updates it, the server must respond with either a 200 (OK) or a 204 (No Content) to show the request was completed successfully.
PATCH: The PATCH method, also named partial PUT can be used to update a portion of the main resource. The PUT method only allows a complete replacement of a resource. The response status code can be 200 (OK)
HEAD: The HEAD method is similar to GET but doesn't return the content of the resource, just the headers. It's useful for getting metadata or checking links without downloading the actual content. The server should send the same headers in a HEAD response as it would for a GET request, but it might leave out some headers that are only created when the content is generated. Although the framing of the request is the same for all methods, including content in a HEAD request is unusual and might cause the server to reject it. Typically, a HEAD request should not include content unless it's made to a server that explicitly supports it. The response to a HEAD request can be cached with 200 (OK).
DELETE: The DELETE method is for removing a resource from the server usually by sending a resource identifier.
If the DELETE request is successfully done then the server should have these status codes:
- a
202 (Accepted)status code if the action will likely succeed but has not yet been enacted. - a
204 (No Content)status code if the action has been enacted and no further information is to be supplied. - a
200 (OK)status code if the action has been enacted and the response message includes a representation describing the status.
TRACE: The TRACE method sends a request to a server asking it to send back the exact message it received. The server should return this message, minus some specific fields, in a 200 (OK) response. Clients should avoid including sensitive information in TRACE requests to prevent it from being exposed in the response.
That's it, Hope you enjoy reading and let's close this post here if you're curious to know more about HTTP reference, I highly recommend reading this RFC