The difference between get and post

 

HTTP request type

The HTTP protocol is actually a standard and specification. It is recommended for everyone to do it, and it is also convenient for some underlying implementations, just like the traffic rules. That is to say, you can do it if you don’t follow it. You can also use other methods to achieve it. You can see this. See reference link 5 (also see the comments), let's talk about the topic below.

There are four main types of requests from the client to the server:

1. GET (get from server)
2. POST (send request data to server)
3. PUT (update)
4. DELETE (delete)

Generally speaking, they correspond to the four operations of checking, adding, changing, and deleting, but in fact, the four operations can generally be completed through GET and POST, so these two are the most used daily.

There are other methods that are used less frequently, such as HEAD, CONNECT, etc. For details, you can go to the reference link 1.

Difference between POST and GET

1. GET is enforced by browsers (POST is optional, but generally supported)
2. GET is idempotent, POST is not
3. GET can be cached by browsers, POST cannot
4. GET requests are "safe", POST is not
5. POST is relatively "safer" than GET
6. Parameter size (ideal and realistic)

idempotent

Idempotent (idempotent, idempotence) is a mathematical and computer science concept commonly used in abstract algebra.
In programming. The characteristic of an idempotent operation is that the impact of any number of executions is the same as the impact of one execution. An idempotent function, or idempotent method, is a function that can be executed repeatedly with the same parameters and achieve the same result. These functions do not affect the system state, and there is no need to worry that repeated execution will cause changes to the system.

Baidu Encyclopedia

For example, abs(-1)=abs(abs(-1)), which means that the data obtained by each GET is unchanged.

GET can be cached

For example, a url is requested through GET, and then some parameters are clearly attached to the url, which can be seen when viewing the browser's historical access. Some files are also cached while being accessed, while the general POST is Will not.

Note: POST requests in RFC can also be cached, but browsers generally do not support it, just like TCP/IP and OSI models, the difference between ideal and reality

GET is relatively "safe"

The security here means that GET will not change the data in the server, while POST will generally change the data

POST is relatively "safe"

This is to say that it is relatively "safe". The url will be accompanied by some parameters of the GET request, but the POST request will not be seen in the url.

Note: The captured packets can be seen, and they are all transmitted in plain text.

parameter

The RFC does not limit the size of the parameters of the request, but in fact, the browser has a limit on the length of the url, and generally also imposes some restrictions on the data size of the POST, so it is also a manifestation of the inconsistency between the standard and the browser.