Http defines different methods for interacting with the server. There are four most basic methods, namely GET, POST, PUT, and DELETE. The full name of URL is resource descriptor. We can think of it like this: a URL address, which is used to describe a resource on the network, and GET, POST, PUT, DELETE in HTTP corresponds to the query, modification, addition of this resource, Delete 4 operations. At this point, you should have a general understanding, GET is generally used to obtain/query resource information, and POST is generally used to update resource information.
1. According to the HTTP specification, GET is used for information retrieval and should be safe and idempotent.
(1). The so-called safe means that the operation is used to obtain information rather than modify it. In other words, GET requests should generally not have side effects. That is to say, it only obtains resource information, just like a database query, it will not modify or add data, and will not affect the state of the resource.
* Note: The meaning of security here only refers to non-modified information.
(2). Idempotent means that multiple requests to the same URL should return the same result. Here I explain the concept of idempotency again:
There are several definitions of idempotency:
For unary operations, if an operation is performed multiple times for all a number in the range, the result obtained by the operation is the same as the result obtained by performing the operation once, then we call the operation. Operations are idempotent. For example, absolute value operation is an example. In the set of real numbers, there is abs(a)=abs(abs(a)).
For the binocular operation, it is required that when the two values involved in the operation are equal, if the result of the operation is equal to the two values involved in the operation, the operation is called idempotent, such as finding the maximum value of two numbers. A function that is idempotent in the set of real numbers, ie max(x,x) = x.
After reading the above explanation, you should be able to understand the meaning of GET idempotency.
However, in practical application, the above two regulations are not so strict. An example of citing someone else's article: For example, the front page of a news site is constantly updated. Although the second request returns a different batch of news, the operation is still considered safe and idempotent because it always returns the current news. Fundamentally, if the goal is that when a user opens a link, he can be confident that the resource has not changed from his own perspective.
2. According to the HTTP specification, POST represents a request that may modify a resource on the server. Continue to cite the above example: Take news as an example, readers should post their own comments on news, because the resources of the site are different after the comments are submitted, or the resources have been modified.
The above has roughly talked about some of the principle problems of GET and POST in the HTTP specification. But in practice, many people do not follow the HTTP specification. There are many reasons for this problem, such as:
1. Many people are greedy for convenience and use GET when updating resources, because POST must go to FORM (form), which will be a little troublesome.
2. The operations of adding, deleting, modifying, and checking resources can actually be done through GET/POST without using PUT and DELETE.
3. Another is that early Web MVC framework designers did not consciously treat and design URLs as abstract resources, so a serious problem is that traditional Web MVC frameworks basically only support GET and POST two HTTP methods, but not PUT and DELETE methods.
* Briefly explain MVC: MVC originally existed in the Desktop program, M refers to the data model, V refers to the user interface, and C refers to the controller. The purpose of using MVC is to separate the implementation code of M and V, so that the same program can use different representations.
The above three points typically describe the old style (not strictly abiding by the HTTP specification). With the development of the architecture, REST (Representational State Transfer), a new style that supports the HTTP specification, has emerged. I won’t say much here. You can refer to " RESTful Web Services ".
After talking about the principle problem, let's take a look at the difference between GET and POST from the surface:
1. The data of the GET request will be attached to the URL (that is, the data will be placed in the HTTP protocol header), the URL and the transmission data are separated by ?, and the parameters are connected by &, such as: login.action?name=hyddd&password=idontknow&verify= %E4%BD%A0%E5%A5%BD. If the data is English letters/numbers, send it as it is, if it is a space, convert it to +, if it is Chinese/other characters, directly encrypt the string with BASE64, and get such as: %E4%BD%A0%E5%A5% BD, where XX in %XX is the ASCII hex representation of the symbol.
POST places the submitted data in the body of the HTTP packet.
2. "The data submitted by GET can only be up to 1024 bytes. In theory, there is no limit to POST, and a larger amount of data can be transmitted. The maximum size is 80KB in IIS4 and 100KB in IIS5"? ? !
The above sentence is transferred from another article. In fact, it is wrong and inaccurate to say this:
(1). First of all, "the data submitted by GET can only be up to 1024 bytes", because GET is to submit data through URL, so the amount of data that can be submitted by GET is directly related to the length of the URL . In fact, there is no upper limit of parameters for URLs, and the HTTP protocol specification does not limit the length of URLs. This restriction is a particular browser and server restriction on it. IE's limit on URL length is 2083 bytes (2K+35). For other browsers, such as Netscape, FireFox, etc., there is no length limit in theory, and the limit depends on the support of the operating system.
Note that this limit is the entire URL length, not just your parameter value data length . [see Reference 5]
(2) In theory, there is no size limit for POST, nor does the HTTP protocol specification limit the size. It is inaccurate to say that "the POST data volume has a size limit of 80K/100K". There is no limit to the POST data. The limiting effect is the processing power of the server's handler.
For ASP programs, there is a 100K data length limit when the Request object processes each form field. But if you use Request.BinaryRead there is no such restriction.
From this extension, for IIS 6.0, Microsoft has increased the restrictions for security reasons. We also need to pay attention to:
1). IIS 6.0 default ASP POST data size is up to 200KB, and each form field is limited to 100KB.
2). The maximum size of uploaded files in IIS 6.0 is 4MB by default.
3). The default maximum request header of IIS 6.0 is 16KB.
Before IIS 6.0 there were no such restrictions. [see Reference 5]
So the above 80K and 100K may just be the default values (Note: I have not confirmed the parameters of IIS4 and IIS5), but they can definitely be set by yourself. Since each version of IIS has different default values for these parameters, please refer to the relevant IIS configuration documents for details.
3. In ASP, the server uses Request.QueryString to obtain GET request parameters, and Request.Form to obtain POST request parameters. In JSP, use request.getParameter(\"XXXX\") to obtain, although there is also request.getQueryString() method in jsp, but it is more troublesome to use, for example: pass a test.jsp?name=hyddd&password=hyddd, use What request.getQueryString() gets is: name=hyddd&password=hyddd. In PHP, you can use $_GET and $_POST to get the data in GET and POST respectively, and $_REQUEST can get the data in both GET and POST requests. It is worth noting that the use of request in JSP and the use of $_REQUEST in PHP will have hidden dangers. I will write an article summary next time.
4. The security of POST is higher than that of GET. Note: The security mentioned here is not the same concept as the "security" mentioned in GET above. The meaning of "security" above is only not to modify data, and the meaning of security here is the meaning of real Security, such as: submitting data through GET, the user name and password will appear on the URL in clear text, because (1) the login page may be accessed by Browser cache, (2) Others view the browser's history, then others can get your account and password. In addition, using GET to submit data may also cause a Cross-site request forgery attack.
To sum up, Get is a request to the server for data, and Post is a request to submit data to the server. In the FORM (form), the Method defaults to "GET". In essence, GET and POST are just sending mechanisms. Different, not one take one hair!