This article from: www.cnblogs.com/logsharing/…

GET and POST are the two basic methods of HTTP requests, and anyone who has been involved in WEB development can tell you a thing or two about the differences between them.

The most obvious difference is that GET contains parameters in the URL, while POST passes parameters through the request body.

You’ve probably written countless GET and POST requests yourself, or you’ve seen many authoritative websites summarize their differences, and you know exactly what to use when.

When you are asked this question in an interview, your heart fills with confidence and joy.

You easily gave a “standard answer” :

  • GET is harmless when the browser falls back, while POST resubmits the request.

  • The URL generated by GET can be bookmarked, but not by POST.

  • GET requests are actively cached by browsers, whereas POST requests are not, unless set manually.

  • GET requests can only be url encoded, while POST supports multiple encoding methods.

  • GET request parameters are retained in browser history, while parameters in POST are not.

  • GET requests pass parameters in the URL with length limits, whereas POST does not.

  • GET accepts only ASCII characters for the data type of the argument, while POST has no restrictions.

  • GET is less secure than POST because parameters are exposed directly to the URL and therefore cannot be used to pass sensitive information.

  • The GET argument is passed through the URL, and the POST is placed in the Request body.

“Unfortunately, that’s not the answer!”

Please tell me the truth…

Would you believe me if I told you that GET and POST are essentially the same?

Let’s take off the clothes of GET and POST and be honest.

What are GET and POST? Two methods of sending a request in HTTP.

What is HTTP? HTTP is a TCP/ IP-based protocol for how data is communicated on the World Wide Web.

The underlying layer of HTTP is TCP/IP. So the bottom layer of GET and POST is also TCP/IP, that is, both GET and POST are TCP links. GET and POST can do the same thing. Technically, it makes perfect sense for you to add a request body to GET and a URL to POST.

So what about the differences in “standard answers”?

In the world wide Web, TCP is like a car. We use TCP to transport data. It’s reliable. But if the roads were filled with cars that looked exactly the same, the world would look like a mess, and the delivery cars would be blocked by the cars in front of them with loads of goods, and the entire transportation system would surely break down. To avoid this, traffic rules HTTP was born. HTTP provides several service categories for vehicle transportation, including GET, POST, PUT, DELETE, and so on. HTTP states that when a GET request is executed, the vehicle must be labeled as GET (set method to GET), and the data being transmitted must be placed on the roof of the vehicle (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 hide some goods in the train during GET, but this would be disgraceful; You can also put some data on the roof of the car during POST to make it look silly. HTTP is just a code of conduct, TCP is basically how GET and POST are implemented.

However, we only see that HTTP requires a transport channel (URL or Requrest Body) for GET and POST parameters. Where does the limit on the size of the standard answer come from?

There is another important player in the world wide Web: transportation companies. Different browsers (making HTTP requests) and servers (accepting HTTP requests) are different shipping companies. In theory, though, you can stack an infinite amount of goods on the roof (with an infinite number of parameters in the URL). But shipping companies are not stupid. Loading and unloading costs are high, and they limit the risk of a single shipment. Too much data is a burden on browsers and servers. The unwritten rule of the industry is that (most) browsers generally limit urls to 2K bytes, while (most) servers handle urls up to 64K. Any excess will not be processed. If you use the GET service to hide data in the request body, different servers will handle it differently. Some servers will load the data for you and read it, while others will ignore it. Therefore, although GET can contain the request body, there is no guarantee that it will be received.

Okay, so now you know, GET and POST are essentially TCP links, no different. However, due to HTTP regulations and browser/server restrictions, they are applied differently.

You think that’s the end of this article?

Our big BOSS is waiting to show up…

How mysterious is the BOSS? When you look up “the difference between GET and POST” on the Internet, he’s never mentioned in any of the search results you’ll see. What on earth was he…

There is another important difference between GET and POST, to put it simply:

GET generates a TCP packet; POST generates two TCP packets.

Long said.

For GET requests, the browser sends both HTTP headers and data, and the server responds with 200 (return data).

For POST, the browser sends a header, the server responds with 100 continue, the browser sends data, and the server responds with 200 OK (returns data).

In other words, GET only needs to make one trip to deliver the goods, whereas POST has to make two trips. In the first trip, it goes to the server and says, “Hey, I’m going to deliver the goods later, you can open the door and meet me.” Then it goes back and delivers the goods.

Because POST takes two steps and consumes a little more time, it looks like GET is more efficient than POST. So the Yahoo team has recommended using GET instead of POST to optimize site performance. But this is a pit! Jump with caution. Why is that?

  1. GET and POST have their own semantics and cannot be used together.

  2. According to research, under the condition of good network environment, the time difference between sending a packet and sending two packets can be ignored basically. In the case of poor network environment, the TCP of two packets has great advantages in verifying the integrity of packets.

  3. Not all browsers send packages twice in POST, Firefox only sends them once.

Over!!