Foreword: I believe that the small partners must have encountered this problem during the interview. Even if they have not encountered it, at least they have heard of it. There is a lot of information on the Internet, and probably everyone can say something. But I always felt that the interview was not successful, so I read some information and further sorted it out.
Generally, when we mention the comparison of get and post requests, we intuitively think that:
Features of get request:
1. GET requests can be cached
2. The GET request will be saved in the browser's browsing history
3. The URL requested by GET can be saved as a browser bookmark
4. The amount of data transferred by get is small and cannot be larger than 2KB.
5. The GET request is mainly used to obtain data
Features of post request:
1. POST requests cannot be cached
2. POST requests will not be saved in the browser browsing history
3. The URL requested by POST cannot be saved as a browser bookmark
4. The amount of data transmitted by post is relatively large, and is generally defaulted to be unlimited
But in fact, this is not the most essential difference, haha. (There is a heartbreak in the wood)
Let's start with HTTP for an in-depth look at get and post requests:
1. Transmission channels for GET and POST parameters
get and post are actually two methods of sending requests in the HTTP protocol, and HTTP is a protocol based on TCP/IP about how data is communicated in the World Wide Web.
The bottom layer of HTTP is TCP/IP. So the bottom layer of GET and POST is also TCP/IP, that is to say, GET/POST are all TCP links. GET and POST can do the same thing. You need to add request body to GET and url parameters to POST, which is technically feasible.
So why do we usually feel that there are various differences between get and post?
In the world of the World Wide Web, TCP is actually like a car. We use TCP to transmit data. It is very reliable, and there is never a phenomenon of missing pieces. But think about it, if all the cars running on the road were the same, the whole world would look like a mess. For example, an ambulance carrying an emergency patient may be blocked on the road by a pile of cars full of goods; things that need to be transported urgently are also blocked due to layers of blockages, missing a good opportunity; a calf truck pulling goods broke a leg, Not in time. The so-called non-rules do not form a circle, so that the whole system will be in chaos.
To avoid this from happening, the traffic rules HTTP was born. HTTP sets several service types for automobile transportation, including GET, POST, PUT, DELETE, HEAD, etc. HTTP stipulates that when a GET request is executed, a GET label should be attached to the car (set the method to GET), and the transmitted data should be placed on the roof of the car (in the url) for easy recording. If it is a POST request, put a POST label on the car and put the goods in the car. Of course, you can also secretly hide some cargo in the car during GET, but this is very disgraceful; you can also put some data on the roof of the car during POST, which makes people feel silly. HTTP is just a code of conduct, and TCP is the basis for how GET and POST are implemented.
2. GET and POST parameter size
In the world of the World Wide Web, there is another important role: the transportation company. Different browsers (initiating http requests) and servers (accepting http requests) are different shipping companies. Although in theory, you can have an infinite pile of goods on the roof (infinite parameters in the url). But shipping companies are not stupid. Loading and unloading is also costly. They limit the amount of a single shipment to control risks. Too much data is a huge burden on browsers and servers. The unwritten rule in the industry is that (most) browsers typically limit URL lengths to 2K bytes, while (most) servers handle URLs up to 64K in size. Exceeded part will not be processed. If you use the GET service, the data is secretly hidden in the request body, and the processing methods of different servers are also different. Some servers will help you unload and read the data, and some servers will ignore it directly. Therefore, although GET can carry a request body, it cannot Guaranteed to be received.
Well, now you know that GET and POST are essentially TCP links and there is no difference. However, due to HTTP regulations and browser/server limitations, they show some differences in the application process.
3. Data packets generated by get and post
In addition, there is a major difference between get and post, that is, the get request generates one TCP packet, while the post request generates two TCP packets.
Long said:
For GET requests, the browser will send the http header and data together, and the server responds with 200 (return data);
For POST, the browser sends the header first, the server responds with 100 continue, the browser sends the data, and the server responds with 200 ok (returning data).
That is to say, GET only needs one car trip to deliver the goods, while POST has to make two trips, the first trip, go and say hello to the server "Hey, I'll come to deliver the goods later, you remember to wait for me. ", and then go back and deliver the goods. Because POST takes two steps and consumes a little more time, it seems that GET is more efficient than POST.
Therefore, some companies have recommended to use get requests instead of post requests to optimize performance, but this is actually a pit.
1. GET and POST have their own semantics and cannot be used casually.
2. According to research, when the network environment is good, the difference between the time of sending a packet once and the time of sending two packets can basically be ignored. In the case of poor network environment, the TCP of two packets has great advantages in verifying the integrity of the data packets.
3. Not all browsers send packets twice in POST, Firefox only sends them once.