First give the comparison of w3c :
|
|
GET |
POST |
| back button / refresh |
harmless |
The data will be resubmitted (the browser should inform the user that the data will be resubmitted). |
| bookmark |
bookmarkable |
Not bookmarked |
| cache |
can be cached |
cannot be cached |
| encoding type |
application/x-www-form-urlencoded |
application/x-www-form-urlencoded or multipart/form-data . Use multiple encodings for binary data. |
| history |
Parameters are preserved in the browser history. |
Parameters are not saved in browser history. |
| restrictions on data length |
Yes. When sending data, the GET method adds data to the URL ; the length of the URL is limited ( the maximum URL length is 2048 characters). |
Theoretically unlimited. |
| Restrictions on data types |
Only ASCII characters are allowed . |
no limit. Binary data is also allowed. |
| safety |
GET is less secure than POST because the data sent is part of the URL . Never use GET when sending passwords or other sensitive information ! |
POST is more secure than GET because parameters are not saved in browser history or web server logs. |
| visibility |
The data is visible to everyone in the URL . |
The data will not be displayed in the URL . |
The above are only superficial differences , but what is the underlying root cause? After searching on the Internet, I think the following statement is more reasonable, you can refer to:
Several characteristics of the HTTP method are defined in RFC7231 :
Safe - safe
The meaning of "safety" here is different from the commonly understood "safety". If the semantics of a method is "read-only" in nature, then the method is safe. If the client's request to the server's resources uses a safe method, it should not cause any state changes on the server, so it is also harmless. This RFC defines that the methods GET, HEAD, OPTIONS and TRACE are safe.
However, this definition is only a specification, and does not guarantee that the implementation of the method is also safe. The implementation of the server may not conform to the semantics of the method, as mentioned above in the case of using GET to modify user information.
The purpose of introducing the concept of security is to facilitate web crawlers and caches, so as to avoid some unintended consequences when calling or caching some unsafe methods. The User Agent (browser) should differentiate between safe and unsafe methods and prompt the user.
Idempotent - Idempotent
The concept of idempotency means that executing the same request method multiple times has exactly the same effect as executing it only once. According to the RFC specification, PUT , DELETE and safe methods are all idempotent. Again, this is just a specification, and there is no guarantee that the server implementation is idempotent.
The introduction of idempotency is mainly to deal with the situation where the same request is sent repeatedly, such as losing the connection before the request responds. If the method is idempotent, you can safely resend the request. This is also the reason why the browser will prompt the user when it encounters a POST when backing / refreshing: POST semantics are not idempotent, and repeated requests may have unintended consequences.
Cacheable - Cacheability
As the name implies, it is whether a method can be cached. In this RFC , GET , HEAD and POST in some cases are cacheable, but most browser implementations only support GET and HEAD . For more information on caching see RFC7234 .
The same thing has been emphasized in these three features, that is, the protocol is not equal to the implementation: the protocol stipulates that the security is not necessarily safe in the implementation, the protocol stipulates that the idempotent is not necessarily idempotent in the implementation, and the protocol stipulates that the cache can be cached in the implementation. Must be cacheable. This is actually the relationship between specification and implementation mentioned by the author above .
semantic battle
At this point, I actually understand the difference between these two methods, which is essentially a comparison of "semantics" rather than "syntax", and a comparison of " Specification " rather than " Implementation " .
Regarding the semantics of these two methods, the original text in RFC7231 has written very well:
The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
The POST method requests that the target resource process the representation enclosed in the request according to the resource’s own specific semantics.
translate:
1. The semantics of GET is to request the specified resource . The GET method is safe, idempotent, and cacheable (unless constrained by the Cache-Control Header ) , and the body of the GET method has no semantics.
2. The semantics of POST is to process the specified resource according to the request load (message body), and the specific processing method varies depending on the resource type. POST is not safe, not idempotent, and (most implementations) not cacheable. There are a number of ways to optimize for its uncacheability.
To give a common chestnut, in the scenario of Weibo, the semantics of GET will be used in scenarios such as "look at the latest 20 Weibos on my Timeline ", while the semantics of POST will be used in "Post Weibo, Comments, likes”.