Is javascript-get and post just a convention?

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

Reply content:

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

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

First, the conclusion is that in terms of the security and idempotence of GET and POST, this is not just an agreement but a standard. However, in the standard, security and idempotence are not restricted.

To solve this problem, we have extracted the RFC 7231 document. the previous RFC 2616 has been replaced by RFC7230-RFC7235 six protocol instructions. for method definitions, refer to RFC 7231.

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

Concerning the security methods and idempotence of the subject

Chapter 4.2.1 and 4.2.2 of RFC 7231 clearly define what is "Safe Methods" (Security method) and "Idempotent Methods" (Idempotent method)

Then, in the standard defined in RFC, the security method is defined (not strictly translated)

Request methods are considered "safe" if their defined semantics are essential read-only; I. e ., the client does not request, and does not found CT, 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.

The request method is considered "secure" in the following situations: it is read-only in essence, or when the client applies a method to the resources of an original server, it is not expected that the request results will change in any status. and the use of reasonable security methods will not cause any damage, loss of properties or cause abnormal server load

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 security method does not prevent the implementation of the following behavior: It will cause damage to the result, and it is not completely read-only, or it will produce other side effects. but it is important that (if these changes occur) there are no requests (that is, they are not expected at the request) at the customer level, so the client is not responsible. for example, most servers record the request information to the access log after each request ends, but sometimes whatever the request, even if it is recorded in the log (it looks like) security behaviors may also cause server crashes. similarly, a security request for a Web advertisement usually has a side effect on the advertisement account, that is, billing.

Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are 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 (I also attached my own less rigorous free translation)

A request method is considered "idempotent" if the intended effect on
The server of multiple identical requests with that method is
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.

When a request method is considered to be idempotent in the following situations: if a request has the same effect as a single request in multiple requests, the defined request methods include PUT, DELETE, and other "security methods" are idempotent.

So my conclusion is that, in terms of the security and idempotence of GET and POST, it is not just an agreement, it is a standard, but in the standard, no restrictions on security and Idempotence

(It seems that I did not say it again)

= The following is a hasty original answer =

It should be said that this is a best practice even before reaching the agreed level.

Websites that do not do this are everywhere

But this does not prevent us from conducting this best practice on our own.

Get post is a standard, not just a convention.
The difference between conventions and standards is whether they are enforced.
The agreed execution depends on the individual, and the get post will be faithfully executed by the browser as the standard.
Finally, we will find that GET and POST are different in the browser environment at least.
For example, GET cannot pass Form Data, so in the code, it cannot replace POST With GET completely.

This is a generic rule. it was originally defined as this, but it is not writable to prevent other usage. it can be used flexibly according to my personal opinions.

In my opinion, the particularly popular RESTful is actually to make the real implementation of the http protocol.

If you don't write it like this, you will be laughed at by colleagues...

From the perspective of CURD, no one specifies that GET must be a query, and POST must be an addition, deletion, and modification. This does not mean anything.

Yes, it is conventional.

The method of the application layer http protocol, such as eating with chopsticks, spoon, and forks.

The protocol is set in this way. The protocol means an agreement.
If you implement the client server by yourself, of course you can ignore these conventions. However, if you do some docking work and the other party keeps the conventions, you will not pass the agreement if you do not keep the conventions.

This is an advocate and standard. We strictly oppose abuse. Mobile apps and websites are data-driven upper-layer applications, and communication relies heavily on http. Therefore, I suggest you try to understand the difference between get and post, not just an agreement, but a standard rule. The most important premise is that you cannot use get to modify, delete, and create operations, and there are other differences. To put it deeper, this is the withdrawal of professional capabilities.

For example, if your front and back ends use cookies to save the status, and you use get to add or modify data, why? csrf will translate your website into =