GET and POST are the two basic methods of HTTP requests. If you want to talk about the difference between them, anyone who has been exposed to WEB development can tell one or two. The most intuitive difference is that GET includes parameters in the URL, and POST passes parameters through the request body. There is also the following description:
-
GET is harmless when the browser falls back, while POST submits the request again.
-
The URL address generated by GET can be Bookmarked, but POST cannot.
-
GET requests will be actively cached by the browser, while POST will not, unless manually set.
-
GET requests can only be url encoded, while POST supports multiple encoding methods.
-
GET request parameters will be fully preserved in the browser history, while POST parameters will not be preserved.
-
The parameters passed in the URL of the GET request are limited in length, while POST does not.
-
For parameter data types, GET only accepts ASCII characters, while POST has no restrictions.
-
GET is less secure than POST because the parameters are exposed directly on the URL, so it cannot be used to pass sensitive information.
But let's take off the coats of GET and POST and be honest!
What are GET and POST? Two methods of sending requests in the HTTP protocol.
What is HTTP? HTTP is a protocol based on TCP/IP for how data is communicated on 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.
In my big world of the world wide web, TCP is like a car, we use TCP to transport data, it is very reliable, and there is never a phenomenon of missing pieces. But if the road is full of cars that look exactly the same, the world looks like a mess, and the car delivering the urgent shipment may be blocked on the road by the car full of goods in front, and the entire transportation system will be paralyzed. To avoid this from happening, the traffic rules HTTP was born. HTTP sets several service categories for car transportation, including GET, POST, PUT, DELETE, etc. HTTP stipulates that when a GET request is executed, the car should be labeled GET (set the method to GET), and the request Put the transmitted data 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.
However, we only see HTTP requirements for the delivery channel (url or request body) of GET and POST parameters. Where does the limit on parameter size in the "standard answer" come from?
There is another important role in my larger World Wide Web world: the shipping company. Different browsers (making 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 are added to 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, 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.
There is another important difference between GET and POST. Simply put:
GET produces one TCP packet; POST produces two TCP packets.
Long said:
For GET requests, the browser will send the http header and data together, and the server responds with 200 (returning data); for POST, the browser sends the header first, the server responds with 100 continue, the browser sends the data, and the server responds 200 ok (return data). That is to say, GET only needs one car trip to deliver the goods, while POST has to make two trips. For the first trip, go and say hello to the server "Hey, I'm going to deliver a batch of goods later, you open it. Meet me at the door," before turning back to deliver the goods. Because POST takes two steps and consumes a little more time, it seems that GET is more efficient than POST. Therefore, the Yahoo team recommends replacing POST with GET to optimize website performance. But this is 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.
(This article is borrowed from the WeChat public account WebTechGarden)