prospects

Now in front end interviews some interviewers ask the difference between GET and POST. Personally, most front-end engineers (including me) learn relatively little about the network, and basically focus on the similarities and differences between the use of GET and POST. I think for the front-end development of general corporate needs, it is basically enough to understand the situations in which GET and POST are used, the differences in how they are used, and how to submit data.

Hereby, in the collection of various strengths, sorted out some get and post differences, I hope you use in the interview and work.

Get

  • The data for the GET request is appended to the URL, separated with a question mark, and multiple parameters are concatenated with &.
  • The data for the GET request is exposed in the address bar.
  • GET request urls are encoded in ASCII rather than Unicode.
  • The transfer size of GET requests is limited to 2KB.
  • GET is insecure and will be actively cached by the browser.
  • GET generates a TCP packet, and head and data are sent together.
  • GET Browser rollback is harmless.

POST

  • A POST request places the data in the body of the HTTP request package and is not directly exposed to the user.
  • POST requests are theoretically unlimited in size, but in practice each server regulates the size of the data submitted by POST.
  • POST is more secure than Get because the parameter is not stored in browser vertical or Web server logs.
  • POST generates two TCP packets, the header is sent first, the server responds with 100ms and then continues, sending data, server 200 and then returns data.
  • POST Indicates that the browser rolls back the request again.

No difference in performance

HTTP is a TCP/ IP-based application layer protocol. Both POST and GET use the same transport layer protocol, so there is no difference in transmission.

GET can do the same thing as POST, but it’s technically possible to add a request body to GET and a URL to POST.

The following is a personal think said relatively simple and clear, copy over to everyone to see:

Reference: www.cnblogs.com/mark5/p/110…

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.

I’m sure that’s what most interviewers are looking for