Common HTTP Request Methods and Their Differences

1. Common HTTP Request Methods

The core and commonly used methods are as follows:

GET

Purpose: Request the specified resource. It is only used to retrieve data and should not produce any “side effects” (such as modifying data).
Characteristics: The request parameters are directly appended to the URL (query string), with length limitations, and will be saved in the browser’s history. It can be cached and bookmarked.

POST

Purpose: Submit data to the server, which usually results in a change in the server’s state (such as creating a new resource).
Characteristics: Data is sent in the request body, with no length limitation, and is more secure (not visible in the URL or browser history). It is typically not cached.

PUT

Purpose: Update all content of the specified resource. If the resource does not exist, it can be created using PUT.
Characteristics: The request body contains the complete updated version of the resource. It is idempotent (executing the same PUT operation multiple times yields the same result).

DELETE

Purpose: Delete the specified resource.
Characteristics: The operation is idempotent.

PATCH

Purpose: Partially update the specified resource. Unlike PUT, PATCH only submits the fields that need to be modified, rather than the entire resource.
Characteristics: The request body contains a set of instructions describing how to modify the resource. It is not idempotent (depending on the implementation, but under standard definitions, consecutive identical PATCH requests may yield different results).

2. Other Less Common but Important Methods

HEAD

Purpose: Similar to the GET method, but the server only returns the response headers, not the response body. It is used to check metadata (such as size, type) before downloading large files or to verify link validity.

OPTIONS

Purpose: Inquire which request methods are supported by the server for a specific URL. Commonly used in CORS (Cross-Origin Resource Sharing) preflight requests.

CONNECT

Purpose: Establish a tunnel to the target resource, typically used to create an SSL encrypted channel through a proxy server.

TRACE

Purpose: Perform a message loopback test along the path to the target resource, mainly for diagnostics. Due to security risks (such as XST attacks), it is usually disabled in browsers.

3. Core Comparison Table of Differences

Method	Semantics (Purpose)	Idempotent	Safe	Request Body	Typical Application Scenarios
GET	Retrieve/Query resource	Yes	Yes	Usually none	Accessing web pages, searching, clicking links
POST	Submit/Create resource	No	No	Yes	User login, form submission, file upload
PUT	Complete Update/Create resource	Yes	No	Yes	Updating user profile (providing complete information)
PATCH	Partial Update resource	Usually No	No	Yes	Only modifying user nickname or status
DELETE	Delete resource	Yes	No	Usually none	Deleting an article, a user
HEAD	Get resource metadata	Yes	Yes	None	Checking if a link is valid, whether a resource is updated
OPTIONS	Query supported methods by the server	Yes	Yes	None	CORS preflight request

4. Key Concept Explanations

1. Safety (Safe Methods)

A method is considered “safe” if it is only used to read information and does not modify any data on the server. GET, HEAD, OPTIONS are considered safe methods. Safe methods can be cached and preloaded without causing unintended consequences.

Note: Safety does not mean that the operation has no side effects (such as logging), but rather that the user’s intent is not to modify data.

2. Idempotence (Idempotent Methods)

A method is “idempotent” if the effect of executing the same request once is the same as executing it multiple times (on the server state).

GET: Retrieving the same resource multiple times yields the same result. (Idempotent)
PUT: Updating the same resource with the same data multiple times yields the same result as a single update. (Idempotent)
DELETE: After deleting a resource, deleting it again still results in “deleted”. (Idempotent)
POST: Submitting an order once creates a new order, while submitting it twice creates two orders. (Not Idempotent)

Idempotence is crucial for network communication; when a request fails (e.g., due to a timeout), the client can safely retry idempotent requests without worrying about unintended effects.

Conclusion

RESTful API Design fundamentally leverages the semantics of these HTTP methods.

GET /users – Retrieve user list
POST /users – Create a new user
GET /users/1 – Retrieve user with ID 1
PUT /users/1 – Update user with ID 1 (complete information)
PATCH /users/1 – Update user with ID 1 (partial information)
DELETE /users/1 – Delete user with ID 1

Understanding the differences and applicable scenarios of these methods is fundamental to web development and API design.