The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should not contain a request content. MDN Docs

Retrieves data from a server without making changes.

Example: A user visits a blog and requests the homepage by typing the URL into their browser. GET /blog/homepage retrieves the list of recent posts.

The HEAD method asks for a response identical to a GET request, but without a response body. MDN Docs

Similar to GET but only fetches headers of a resource. Used to check if a resource exists or to inspect metadata.

Example:A monitoring system pings a website to ensure it's up and running without having to download all content. HEAD /blog/homepage returns a status code and headers indicating if the page is available.

The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server. MDN Docs

Submit data to the server, typically to create a new resource.

Example: A user submits a contact form on a website which submits data to the server. POST /contact sends form data (e.g., name, email) to the server to be processed.

The PUT method replaces all current representations of the target resource with the request content. MDN Docs

Update or replace existing resource or create a resource if it doesn't exist.

Example: A user updates their profile information. PUT /user/123/profile replaces the user's profile with new data (e.g., email, username).

The DELETE method deletes the specified resource. MDN Docs

Removes a resource from the server.

Example: A user deletes their account. DELETE /user/123 deletes the user account with ID 123.

The CONNECT method establishes a tunnel to the server identified by the target resource. MDN Docs

Establish a network tunnel, typically for tunneling HTTPS traffic through a proxy server.

Example: A user connects to a tunnel through an HTTP proxy to an HTTPS server. CONNECT www.example.com:443 HTTP/1.1 establishes a tunnel to the HTTPS server at www.example.com over port 443.

The OPTIONS method describes the communication options for the target resource. MDN Docs

Retrieve HTTP methods and capabilities supported by the server.

Example: A client queries the server to determine which methods it supports for a particular resource. OPTIONS /api/users/123 returns a list of supported methods (e.g., GET, PUT, DELETE).

The TRACE method performs a message loop-back test along the path to the target resource. MDN Docs

Echoes back the received request, for diagnostic purposes.

Example: A user is debugging issues with web requests and wants to see what is received at server-side. TRACE /api/users/123 echoes the received request back to the user.

The PATCH method applies partial modifications to a resource. MDN Docs

Partially update a resource.

Example: A user wants to update only their email address without altering other data. PATCH /user/123/profile sends only the email field to update.

Meaning: A method is considered safe if it does not change the state of the server. In other words, the method only retrieves data or performs a read operation, so the method does not have side effects.

Examples: GET and HEAD are safe because they request data without making changes on the server. POST, PUT, and DELETE are not safe because they can change the state of the server.

Use case: Safe methods are used when the client wants to fetch data without causing side effects on the server.

Meaning: A method is idempotent if making the same request multiple times has the same effect as making it once. The state of the server remains the same after the first successful execution.

Examples: GET, HEAD, PUT, and DELETE are idempotent. GET always returns the same resource, PUT replaces a resource, so multiple identical requests result in the same final state, and DELETE removes a resource, and if you try to delete the same resource multiple times, the resource remains deleted and the server will be in the same state. POST is not idempotent because it can create new resources, so repeated requests can result in multiple resources being created.

Use case: Idempotency is important when requests might be retried (e.g., due to network issues) as it ensures that re-sending the same request doesn't cause additional unintentional changes.

Meaning: A method is cacheable if the response can be cached for future use, to avoid fetching the same data repeatedly.

Examples: GET is cacheable because its responses often conrtain static content or data that doesn't change frequently. POST can be cacheable in specific cases, but it's less common because POST is often used for actions like creating resources, so responses may vary. PUT and DELETE are not cacheable because they modify resources and storing their responses can lead to stale or incorrect data.

Use case: Caching improves performance by decreasing the number of server requests for frequently accessed resources.