The Difference Between GET and POST#

The purpose of the Hypertext Transfer Protocol HTTP is to ensure communication between the client and the server. The HTTP protocol operates through a request-response mechanism between the client and the server, and the two most commonly used methods for request-response are GET and POST.

Differences#

• GET is safe and idempotent, while POST is unsafe and not idempotent.
• Navigating back or refreshing a browser after a GET request has no impact, whereas with a POST request, data will be submitted again.
• The URL generated by GET requests can be saved as a bookmark, whereas this cannot be done with POST.
• Browsers actively cache GET requests, but not POST requests.
• GET requests can only perform URL encoding, while POST supports multiple encoding types.
• Parameters from GET requests are fully retained in the browser's history, unlike those from POST requests.
• The length of parameters sent in a GET request is limited by the URL length, while the size of a POST request depends on the server configuration.
• GET parameters only accept ASCII character data types, while POST has no such limitation and can transmit binary data.
• GET is less secure than POST because its parameters are directly exposed in the URL, making it unsuitable for transmitting sensitive information.
• Parameters from GET requests are directly visible in the URL, while those from POST requests are placed in the Request Body and are not directly visible.

Detailed Explanation#

The differences mentioned above are specific to the implementation of GET and POST in browsers. For example, the widely used Promise is an implementation of the Promise/A+ specification found at promisesaplus.com. The draft of the specification for HTTP/1.1 in the RFC mentions the term "semantics," which defines what kind of action a particular type of request should have. For example, the semantics of GET should be to retrieve resources, while the semantics of POST should be to modify resources. It is possible to implement actions that contradict semantics, such as modifying resources using GET or retrieving resources using POST, or even sending a body with a GET request (assuming the server is able to parse it). While these actions are legal requests, they go against the semantics and may have unintended consequences. Therefore, at its core, the difference between GET and POST lies in their semantics. In fact, it can be understood that GET and POST are not fundamentally different – as long as the client and server can cooperate in sending and receiving, one sends and the other receives. The aforementioned differences are mainly related to the specific implementation in browsers.

Regarding security and idempotence, security means that accessing an interface does not change the state of the server resources, and idempotence means that accessing the same URI multiple times result in the same resource state.

• GET: safe, idempotent, used for reading resources.
• POST: unsafe, not idempotent, used for the server to automatically generate instance numbers and create or update resources.
• PUT: unsafe, idempotent, used for the client to create and update resources with an instance number.
• DELETE: unsafe, idempotent, used for the client to delete resources with an instance number.

When using the browser's back button, if the page to be returned to was reached through a GET request, the browser will safely go back. For a page reached through a POST request, such as when submitting data and redirecting the page using a <form> with the method set to POST, the browser will prompt whether to resubmit the form.

Regarding the limitation on parameter lengths for GET and POST submissions, GET submits data through the URL, so the amount of data that GET can submit is directly related to the maximum URL length that can be achieved. In practice, there is no limitation on the URL length in the HTTP protocol, but different browsers impose their own limits on the URL length, typically not exceeding 4K. Additionally, servers also have their own restrictions on the URL length that they can accept, which can be configured. Similarly, the HTTP protocol does not impose any restrictions on POST data. The size of data that can be submitted through POST is generally limited by the server's configuration.

When it comes to sensitive information, there are two main reasons not to use GET for transmission. First, using GET to transmit sensitive information will directly expose it in the URL, making it visible to anyone. Additionally, parameters transmitted via GET will be directly saved in the browser's history and server logs. Moreover, the HTTP protocol itself is plaintext, so in situations such as man-in-the-middle attacks, the transmitted data can be obtained whether using GET or POST. To prevent such attacks, it is necessary to use HTTPS for encrypted transmission of data.

As for the issue of sending one request with GET and two requests with POST, this is merely a specific implementation of the HTTP protocol by different browsers and doesn't involve the fundamental difference between GET and POST. The specific implementation varies across browsers, primarily related to the underlying optimization of network requests. For example, if a large file needs to be transmitted using POST, the browser might initially send a data packet with a small amount of data to check if the server can receive the file. The server always fully parses all request headers when processing uploaded files, in order to understand the control information and decide whether to accept or reject the request. If the server approves the file, the client will continue uploading data; otherwise, the upload will be terminated to save bandwidth and improve data throughput. This optimization is independent of the HTTP protocol and is a specific implementation by browsers. For instance, the browser may internally set to only send the request header first if the POST data exceeds 1KB; otherwise, it will send all at once. The client can even implement adaptive strategies, such as statistically monitoring the success rate of data transmission and choosing the most efficient method accordingly. Different browsers may have their own approaches, but the ultimate goal of optimization is always to improve data throughput and reduce bandwidth waste. Regardless of how browsers send requests, they always comply with the HTTP protocol and the nature of their implementation doesn't affect the fundamental difference between GET and POST.

Every Day\'s Question#

References#