javascript - Are get and post just conventions?

For example, we say get is idempotent and safe? Does this mean that this is just a rule? We can also use get as post through code (non-idempotent and non-safe)

Reply content:

For example, we say get is idempotent and safe? Does this mean that this is just a rule? We can also use get as post through code (non-idempotent and non-safe)

There are quite a lot of answers, and there are various opinions, so for the sake of rigor, I decided to do some research

The first conclusion is that in terms of the security and idempotence of GET and POST, this is not just a convention, it is a standard, but in the standard, there are no constraints on security and idempotence

In order to solve this problem, I dug out the RFC 7231 document. The previous RFC 2616 has been replaced by six protocol descriptions RFC7230 - RFC7235. Regarding method definition, it is in RFC 7231

https://tools.ietf.org/html/r...

As far as the security method and idempotent method that the subject is concerned about

Chapter 4.2.1 and 4.2.2 of RFC 7231 clearly define what "Safe Methods" and "Idempotent Methods" are

Then in the standard defined in RFC, the definition of security method is (with my own loose translation)

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource . Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

Request methods are considered "safe" when they are: Read-only in nature, or when the client applies a method to an origin server resource and does not expect any state in the result of the request changes. And using reasonable security methods will not cause any damage, loss of properties or cause abnormal load on the server

This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and crash the server. Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.

The definition of this safe method does not prevent the implementation of behaviors that harm the result, are not completely read-only, or produce other side effects. But the important thing is that (if these changes occur), from the customer level it does not These behaviors occur without a request (that is, without expectation at the time of the request), so the client is not responsible. For example, most servers will log request information to the access log after each request, but sometimes no matter Regardless of the request, even the (seemingly) safe behavior of logging may cause the server to crash. Likewise, a safe request for an ad on the web will often have side effects on the ad account, namely billing

Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.

Under the definition of this request method, the GET, HEAD, OPTIONS and TRACE methods are defined to be safe

The definition of idempotent method is (also attach my own loose translation)

A request method is considered "idempotent" if the intended effect on
the server of multiple identical requests with that method is the
same as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE , and safe request methods
are idempotent.

A request method is considered idempotent in the following situations: If a request produces the same effect in multiple requests as in a single request, the request methods defined include PUT, DELETE, and other "safe methods" It’s also idempotent

So my conclusion is that in terms of the security and idempotence of GET and POST, this is not just a convention, it is a standard, but in the standard, there are no constraints on security and idempotence

(It seems like saying it means not saying it yet)

---

== Here is the hasty original answer ==

It has not even reached the level of agreement, it should be said that this is a best practice

There are many websites that don’t do this

But this does not prevent us from carrying out this best practice ourselves

GET POST is a standard, not just a convention.
The difference between a convention and a standard is whether it is enforced.
The execution of the agreement depends on the individual, and GET POST as a standard will be faithfully executed by the browser.
Finally we will find that there are some differences between GET and POST, at least in a browser environment.
For example: GET cannot pass Form Data, so in the code, GET cannot be completely used to replace POST.

This is a general rule. The original definition is to use it this way, but it is not hard-coded to prevent other uses. It can be used flexibly according to personal opinions

Yes, in my opinion, RESTful, which is particularly popular now, is actually the real implementation of the http protocol

If you don’t write like this, your colleagues will laugh at you. . .

From the perspective of CURD, no one stipulates that GET must be a query, and POST must be an addition, deletion, and modification. There is no such meaning.

Yes, it is a convention.

Methods of the application layer http protocol, such as eating with chopsticks, spoons, and forks.

This is how the agreement is made. The meaning of the agreement is an agreement.
If you implement the client server yourself, you can of course ignore these agreements; however, if you do some docking and the other party abides by the agreement, you will not be allowed to pass if you do not abide by the agreement.

This is an advocate and standard. Abuse is strictly prohibited. Mobile apps and websites are both data-driven upper-layer applications, and communication relies heavily on the http protocol, so I would suggest that everyone understand the difference between get and post as much as possible. It is not just a convention but a standard rule. When it comes to modification, deletion and creation operations, get cannot be used. There are other differences, which is the most important prerequisite. To put it more deeply, this is a demonstration of professional ability.

For example, if your front-end and back-end use cookies to save state, and you use get to add or modify data, CSRF will ruin your website = =