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 in contact with WEB development can say one or two.
The most intuitive difference is that GET includes the parameters in the URL, and POST passes the parameters through the request body.
You may have written countless GET and POST requests yourself, or have seen the differences between them summarized by many authoritative websites. You know exactly when and what to use.
When you are asked this question in the interview, your heart is full of confidence and joy.
You easily gave a "standard answer":
- GET is harmless when the browser rolls back, while POST will submit the request again.
- The URL address generated by GET can be Bookmarked, but not by POST.
- 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 completely retained in the browser history, while POST parameters will not be retained.
- The parameters transmitted in the URL of a GET request are limited in length, but not for POST.
- For the data type of the parameter, GET only accepts ASCII characters, while POST has no restrictions.
- GET is less secure than POST, because parameters are directly exposed on the URL, so it cannot be used to transmit sensitive information.
- GET parameters are passed through the URL, and POST is placed in the Request body.
(The answer to this standard is referenced from w3schools)
"Unfortunately, this is not the answer we want!"
Please tell me the truth. . .
Would you believe it if I tell you that GET and POST are essentially the same?
Let's take off the coat of GET and POST and meet frankly!
What are GET and POST? There are two methods of sending requests in the HTTP protocol.
What is HTTP? HTTP is a TCP/IP-based protocol on 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 both TCP links. GET and POST can do the same thing. You have to add request body to GET and url parameter to POST, which is completely technically feasible.
So, what are the differences in the "standard answer"?
In my big 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 or missing items. But if there are all cars that look exactly the same on the road, the world looks like a mess. The cars delivering urgent items may be blocked on the road by cars full of cargo in front, and the entire transportation system will definitely be paralyzed.
In order to prevent this from happening, the traffic rule HTTP was born. HTTP sets several service categories for automobile transportation, such as GET, POST, PUT, DELETE, etc. HTTP stipulates that when a GET request is executed, the car must be labeled with a GET label (set method to GET) and require Put the transmitted data on the roof of the car (in the url) to facilitate recording. If it is a POST request, a POST label must be attached to the car and the goods should be placed in the compartment.
Of course, you can also secretly hide some goods in the carriage during GET, but this is very shameful; 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 of how GET and POST are implemented.
However, we only see HTTP requirements for the delivery channel of GET and POST parameters (url or requrest body). Where does the limitation on parameter size in the "standard answer" come from?
In my big World Wide Web, there is another important role: transportation company. Different browsers (initiating http requests) and servers (receiving http requests) are different transportation companies. Although in theory, you can pile up unlimited goods on the roof of the car (infinitely add parameters in the url).
But the transportation company is not stupid. Loading and unloading are also very costly. They will limit the single transportation volume to control the risk. The large amount of data is a great burden on the browser and the server. The unwritten rule in the industry is that (most) browsers usually limit the URL length to 2K bytes, and (most) servers handle up to 64K URLs.
The excess part will not be processed. If you use the GET service and you secretly hide data in the request body, 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 the request body, it cannot It is guaranteed to be received.
Okay, now you know that GET and POST are essentially TCP links, and there is no difference. However, due to HTTP regulations and browser/server restrictions, they show some differences in the application process.
Our big boss is still waiting to appear. . .
How mysterious is this boss? When you try to find "the difference between GET and POST" on the Internet, the search results you will see never mention him. What is he? . .
There is another important difference between GET and POST. Simply put:
GET generates one TCP data packet; POST generates two TCP data packets.
Long said:
- For GET requests, the browser will send the http header and data together, and the server will respond with 200 (return data);
- For POST, the browser first sends the header, the server responds with 100 continue, the browser then sends data, and the server responds with 200 ok (return data).
In other words, GET requires only one car run to deliver the goods, while POST has to run two times. The first one is to say hello to the server, "Hey, I will deliver a batch of goods later, you open it." The door greeted me", and then went back to deliver the goods.
Because POST requires two steps and consumes a little more time, it seems that GET is more effective than POST. Therefore, the Yahoo team recommends replacing POST with GET to optimize website performance. But this is a pit! Be cautious when jumping in. why?
1. GET and POST have their own semantics and cannot be mixed casually.
2. According to research, when the network environment is good, the difference between the time of sending a packet and the time of sending two packets can basically be ignored. In the case of a poor network environment, two-packet TCP has great advantages in verifying the integrity of the data packet.
3. Not all browsers will send the packet twice in POST, but Firefox will only send it once.
Now, when the interviewer asks you "The difference between GET and POST", is this in your heart?
the end! ! !
Author: On the way
Source: cnblogs.com/logsharing/p/8448446.html
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。