1. According to the HTTP specification, get is used for information acquisition and should be secure and idempotent.
(1). So-called security means that the operation is used to obtain information rather than modify information. In other words, GET requests generally should not have side effects. That is, it simply gets the resource information, just like a database query, without modification, adding data without affecting the state of the resource.
* Note: The meaning of security here is simply non-modification information.
(2). Idempotent means that multiple requests to the same URL should return the same result, or in another way, that the GET request will be cached.
After reading the above explanations, you should be able to understand the meaning of get idempotent.
But in practical applications, the above 2 rules are not so strict. Cite examples of other people's articles: for example, the front page of news sites is constantly being updated. Although the second request returns a different batch of news, the operation is still considered safe and idempotent, as 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 is not changed from its point of view.
2. According to the HTTP specification, post represents a request that may modify resources on the server. Continue to cite the example above: or the news to the website as an example, readers of the news to publish their own comments should be done through post, because after the comments submitted site resources have been different, or that the resources have been modified. Post requests are not cached.
It probably says something about the original reason for Get and post in the HTTP specification. But in the actual time, many people do not follow the HTTP specification to do, the cause of this problem is many, for example, say:
1. Many people are greedy and use get when updating resources, because the post must go to the form (form), which can be a bit troublesome. And the GET request can tell the data to be appended to the URL
2. The increase of resources, delete, change, check operation, in fact, can be completed through get/post, do not need to use put and delete.
3. Another is that the early web MVC framework designers did not consciously view and design URLs as abstract resources, so a more serious problem is that the traditional web MVC framework basically only supports get and post two HTTP methods, The put and delete methods are not supported.
After talking about the original reason, let's look at the difference between the get and post from the surface as above:
1. The data for the GET request is appended to the URL (that is, the data is placed in the HTTP protocol header), to split the URL and transfer the data, the parameters are connected &
Post submits the data to the packet in the HTTP packet.
2. " The data submitted by the Get method can only be 1024 bytes, in theory there is no limit to post, can be transmitted a large amount of data "
The above sentence I transferred from other articles, in fact, this is wrong, inaccurate:
(1). First, "The data submitted by the Get method can only be 1024 bytes," Because get is the data submitted through a URL, then the amount of data that get can commit is directly related to the length of the URL. In fact, the URL does not have the upper limit of the argument, the HTTP protocol specification does not limit the length of the URL. This restriction is restricted to specific browsers and servers. IE's limit on URL length is 2083 bytes (2k+35). For other browsers, such as Netscape, Firefox, etc., there is theoretically no length limit, and its limitations depend on the support of the operating system.
Note that this is the limit for the entire URL length, not just your parameter value data length.
(2). In theory, the post is no size limit, the HTTP protocol specification is not a size limit, said "post data volume exists 80k/100k size limit" is inaccurate, post data is not limited, the limit is the processing capacity of the server handler.
3. The security of post is higher than the security of get.
Note: The security described here is not the same concept as the "security" mentioned in get above. The meaning of "security" above is simply not to make data changes, and the meaning of security here is the meaning of true security, such as: submit data through get, user name and password will appear in plaintext on the URL, because (1) the login page may be cached by the browser, (2) Other people to view the browser's history, Then other people can get your account number and password, in addition, using get to submit data may also cause Cross-site request forgery attack.
To summarize, get is a request to send data to the server, and post is a request to submit data to the server, in form (form), the method defaults to "get", in essence, get and post just send mechanism is different, not one to take a hair!
Collation: The difference between get and post