2.8 HTTP Methods

This is a historical learning note and may contain outdated or incomplete understanding.

1. What Are HTTP Methods?

HTTP/1.0 defined three request methods: GET, POST, and HEAD. HTTP/1.1 added six request methods: OPTIONS, PUT, PATCH, DELETE, TRACE, and CONNECT.

No.	Method	Description
1	GET	Requests information from the specified page and returns the entity body.
2	HEAD	Similar to GET, except that the response has no specific body content and is used to obtain headers.
3	POST	Submits data to a specified resource for processing (for example, submitting a form or uploading a file). The data is included in the request body. A POST request may create a new resource and/or modify an existing resource.
4	PUT	Replaces the contents of the specified document with data sent from the client to the server.
5	DELETE	Requests that the server delete the specified page.
6	CONNECT	Reserved in HTTP/1.1 for proxy servers that can switch a connection into tunnel mode.
7	OPTIONS	Allows a client to inspect server capabilities.
8	TRACE	Echoes the request received by the server, mainly for testing or diagnostics.
9	PATCH	Supplements PUT and is used to partially update a known resource.

2. Properties of HTTP Methods

2.1. Safe

Refers to whether a method is read-only. GET, HEAD, OPTIONS, and TRACE are safe methods.

2.2. Idempotent

Executing the same request method multiple times has exactly the same effect as executing it once. Idempotency is introduced to handle cases where the same request is sent repeatedly.
HTTP GET is used to retrieve resources and should have no side effects, so it is idempotent. For example, GET http://www.bank.com/account/123456 does not change resource state; calling it once or N times has no side effects.
HTTP HEAD is essentially the same as GET, except that HEAD does not contain presentation data and returns only HTTP headers. It should have no side effects and is also idempotent. HEAD can be used for health checks.
HTTP OPTIONS is mainly used to obtain the methods supported by the current URL, so it is also idempotent. If the request succeeds, the HTTP headers contain an Allow header whose value lists the supported methods, such as GET, POST.
HTTP DELETE is used to delete resources and has side effects, but it should be idempotent. For example, DELETE http://www.forum.com/article/4231: calling it once or N times has the same side effect, namely deleting the post with ID 4231. Therefore, the caller can invoke it repeatedly or refresh the page without worrying about additional effects.
HTTP POST is used to create resources. The corresponding URI is not the resource being created itself, but the operator that performs the creation action. It has side effects and is not idempotent. For example, POST http://www.forum.com/articles means creating a post under http://www.forum.com/articles. The HTTP response should contain the creation status and the URI of the post. Two identical POST requests create two resources on the server with different URIs, so POST is not idempotent.
HTTP PUT is used for create or update operations. Its URI is the resource being created or updated. It has side effects but should be idempotent. For example, PUT http://www.forum/articles/4231 means creating or updating the post with ID 4231. Multiple PUT requests to the same URI have the same side effects as one PUT request, so PUT is idempotent.

2.3. Cacheable

Whether a method can be cached. In this RFC, GET, HEAD, and POST in some cases are cacheable.

3. How POST Prevents Duplicate Form Submission

When entering the form page, call a backend API to return a token and place it in a hidden field for submission together with the form. The backend checks whether the token exists in Redis. If it exists, delete it and submit; otherwise, report that it has already been submitted.

4. GET vs. POST

	GET	POST
Semantics	Request the specified resource	Process the specified resource according to the request payload (message body); the exact processing depends on the resource type
Safe	√	×
Idempotent	√	×
Cacheable	√ (unless constrained by a Cache-Control header)	× (in most implementations)
Parameter location	Appended after `?` in the URL	In the body