The difference between get and post
The difference between get and post can be seen from three levels: Browser / server level, HTTP protocol level and semantic level.
Browser / server level
There are many differences between the two at the browser level:
However, these are only appearances. We can say that the browser implements the HTTP protocol to some extent, but we can't say that the behavior of the browser is the provision of the HTTP protocol.
Get and post are defined by the HTTP protocol. There is no relationship between which method to use and how the data in the application layer is transmitted. HTTP never requires that post must be placed in the request body and get must be placed in the URL. In the HTML standard, there is a similar definition. But this is only the Convention of the HTML standard on the usage of the HTTP protocol. In other words, there is no difference between get and post. Just because of the implementation of various browsers and other software, it has become a well-known phenomenon: get uses URL to pass parameters, and post uses body to pass parameters.
The HTTP protocol also clearly points out that neither the HTTP request header nor the request body has a length requirement. It is only due to HTTP regulations and browser / server restrictions that they show some differences in the application process.
Data transmission level
In data transmission, the difference between the two is that get generates a TCP packet; Post generates two TCP packets. For get requests, the browser will send HTTP header and data together, and the server will respond 200 (return data); for post, the browser will first send header, and the server will respond 100 (continue), and then send data, and the server will respond 200 (return data).
Semantic level
What I said earlier is practice or behavior, not specification, or semantics. Semantics indicates the nature or meaning of behavior. For example, the semantics of get is "acquiring resources" and the semantics of post is "processing resources". When implementing these two methods, we must consider their semantics and make behaviors that conform to their semantics.
Explain a few nouns
security
The meaning of "security" here is different from that commonly understood. If the semantics of a method is "read-only" in essence, then the method is secure. If a secure method is used for the request from the client to the server's resources, it should not cause any state change of the server, so it is harmless. This RFC defines that the methods get, head, options and trace are secure. 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 comply with the method semantics, as mentioned above, when using get to modify user information. The purpose of introducing the concept of security is to facilitate web crawlers and caching, so as to avoid some unexpected consequences when calling or caching some unsafe methods. The user agent (browser) should distinguish between safe and unsafe methods and give a prompt to the user.
idempotent
The concept of idempotence means that the same request method is executed multiple times and only once. According to RFC specification, put, delete and security methods are idempotent. Similarly, this is only a specification, and whether the server implementation is idempotent cannot be guaranteed. Idempotent is mainly introduced to handle the repeated sending of the same request, such as losing the connection before the request response. 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 post during back / refresh: Post semantics are not idempotent, and repeated requests may bring unexpected consequences.
Cacheability
As the name implies, whether a method can be cached. Get, head and post in some cases in this RFC are cacheable, but most browser implementations only support get and head. For more information about caching, see rfc7234.