Javascript-get,post is it just a pact?

For example, we say get is idempotent and safe? Is this just a rule, we can also use the code to get a post (non-idempotent and non-secure)

Reply content:

For example, we say get is idempotent and safe? Is this just a rule, we can also use the code to get a post (non-idempotent and non-secure)

The answer is quite a lot, all kinds of statements have, so for the sake of rigor, or decided to do some investigation

The first conclusion is that, in terms of the security and idempotent nature of Get and post, this is not just a convention, it is a standard, but in standards, security and power are not constrained

In order to solve this problem, to go through the RFC 7231 document, the previous RFC 2616 has been rfc7230-rfc7235 Six protocol description replaced, about the method definition, in RFC 7231

HTTPS://TOOLS.IETF.ORG/HTML/R ...

In terms of the safety methods and Idempotent methods that the Lord cares about

The 4.2.1 chapters and 4.2.2 chapters of RFC 7231 clearly define what is "safe Methods" (security method) and "Idempotent Methods" (Idempotent method)

The definition of a security method is then defined in the RFC (with its own non-rigorous transliteration)

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

The request method is considered "safe" in the following cases: It is essentially read-only, or when a client applies a method to a resource on a raw server, it does not expect that the result of the request will change in any state. And the use of reasonable security methods does not cause any damage, loss of attributes or the server's abnormal load

This definition of safe methods does not prevent a implementation from including behavior so is potentially harmful, th At isn't entirely read-only, or that causes side effects while invoking a safe method. What are important, however, is, the client does not request this 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 O f the method, and that are 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 would often has the side effect of charging an Advertising account.

The definition of this security method does not prevent the implementation of the following behavior: It hurts the result, is not completely read-only, or has other side effects. However, it is important that (if these changes are made), there is no request from the customer level (that is, not expecting it at the request), so the client is not responsible. For example, most servers log request information to the access log after each request ends, but sometimes it can cause the server to crash, regardless of the request, even if it is a (seemingly) safe behavior for logging. Similarly, security requests for ads on a web typically have side-effects on the ad account, which is billed

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

In the definition of this request method, the GET, HEAD, Options, and trace methods are defined as safe

The definition of Idempotent method is (also attach oneself not rigorous paraphrase)

A Request method is considered "idempotent" if the intended effect on
The server of multiple identical requests with this method is the
Same as the effect for a single such request. The Request methods
Defined by this specification, PUT, DELETE, and safe request methods
Is idempotent.

When a request method is considered idempotent in the following cases: If a request has the same effect as a single request, the request method defined here includes PUT, DELETE, and other "security methods" that are idempotent.

So my conclusion is that, in terms of the security and power of Get and post, it's not just a convention, it's a standard, but in standards, security and power are not constrained.

(So it seems as if it's not said)

= = The following is a hasty original answer = =

Not even at the agreed level, it should be said to be a best practice.

Sites that do not do so abound

But that doesn't prevent us from doing this best practice ourselves.

GET POST is a standard, not just a convention.
The difference between a contract and a standard is whether it is enforced.
The execution of the contract is personal, and the Get POST is performed faithfully by the browser as a standard.
Finally, we will find that there are some differences between GET and POST in the browser environment at least.
For example: Get cannot pass Form Data, so in the code, you cannot completely replace POST with get.

This is a generic rule that was originally defined to be used in this way, but it also did not write dead to let other usages, according to personal view flexible use

To me it seems that the special fire of the restful is actually to make the HTTP protocol real landing

If you don't write like that, you'll be laughed at by colleagues ...

From the point of view of curd, no one rules GET must be a query, POST must be to increase the deletion. There is no such meaning.

Yes, it's a conventional one.

Application layer HTTP protocol method, such as eating with chopsticks to eat, spoon to eat, fork to eat.

This is the agreement, the agreement means a contract.
If you implement the client server, of course, regardless of these conventions, but if you do some docking, the other party abide by the agreement, you will not be allowed to pass the compliance.

This is an advocate and a standard. Strictly against abuse. Mobile apps and websites are data-driven upper-level applications, and communication relies heavily on the HTTP protocol, so I would recommend that you understand the difference between get and post as much as possible, not just a convention but a standard rule. It is one of the most important prerequisites for anything that involves modifying a delete creation operation, not using get, and other aspects of the difference. Speak a little deeper, this is the withdrawal of professional ability.

For example, if your front and back end with a cookie to save the state, and you use get to add or modify the data, spicy, CSRF will turn your website into the day =

