javascript - get，post是不是仅仅是个约定？

比如我们说get是幂等和安全的？是不是说这只是规定,我们也能通过代码把get当post用（非幂等和非安全）

回复内容：

比如我们说get是幂等和安全的？是不是说这只是规定,我们也能通过代码把get当post用（非幂等和非安全）

答案还挺多的, 各种说法的都有, 所以为了严谨起见, 还是决定去做了一些调查

首先结论是, 就GET和POST的安全性和幂等性而言, 这不仅仅是个约定, 是标准, 但是在标准中, 并没有对安全性和幂等性作出约束

为了解决这个问题, 去翻出了RFC 7231文档, 以前的RFC 2616已经被RFC7230 - RFC7235六份协议说明所替代, 关于方法定义的, 在RFC 7231里面

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

就题主关心的安全方法和幂等方法而言

RFC 7231的4.2.1章节和4.2.2章节中明确定义了什么是"Safe Methods"(安全方法)和"Idempotent Methods"(幂等方法)

然后 RFC 中定义的标准中, 安全方法的定义是(附自己不严谨的意译)

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.

请求方法在如下情况中被认为是"安全"的: 本质上来说是只读的, 或者说当客户端应用一个方法于一个原始服务器的资源时, 并不期望请求的结果会有任何状态上的改变时. 以及使用合理的安全方法不会造成任何损害, 丢失属性或者造成服务器的异常负载

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.

这个安全方法的定义并不阻止如下行为的实现: 对结果产生伤害, 并且不是完全只读, 或者产生其他副作用. 但是重要的是, (如果说这些改变产生了), 从客户层面来说并没有请求(也就是说在请求时并不期望)这些行为产生, 所以客户端是没有责任的. 例如, 大多数服务器会在每个请求结束后都记录请求信息到访问日志中, 但有时候不管是什么请求, 即使是记录日志这种(看起来)安全的行为也有可能导致服务器崩溃. 同样的, 对于一个Web上的广告的安全请求通常也会对广告账户产生副作用也就是进行计费

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

在这个请求方法的定义下, GET, HEAD, OPTIONS和TRACE方法被定义成是安全的

幂等方法的定义是(同样附上自己不严谨的意译)

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.

当请求方法在如下情况中被视为是幂等的: 如果一个请求在多个请求和单个请求产生的效果是相同的, 由此定义的请求方法包括 PUT, DELETE, 以及其它"安全方法"也是幂等的

所以我的结论就是, 就GET和POST的安全性和幂等性而言, 这不仅仅是个约定, 是标准, 但是在标准中, 并没有对安全性和幂等性作出约束

(这么看来好像说了又等于没说)

---

== 以下是草率的原答案 ==

甚至还没到约定的层面, 应该说这是一个最佳实践

没有这么干的网站比比皆是

但这不妨碍我们自己来进行这个最佳实践

GET POST 是标准，而不只是约定。
约定和标准的区别在于是否被强制执行。
约定的执行靠个人，而 GET POST 作为标准是会被浏览器忠实执行的。
最后我们会发现在至少在浏览器环境中，GET 和 POST 是有一些区别的。
比如：GET 无法传 Form Data，于是在代码里，就无法完全用 GET 替代 POST 。

这是一个泛规则，原本定义是这样使用的，但它也没有写死不让其他用法，根据个人看法灵活使用

对 在我看来 现在特别火的RESTful 其实就是使http协议真正的落地

不这么写会被同事们笑话。。。

从 CURD 的角度来看，没人规定 GET 就一定是查询，POST 就一定是增删改。没有任何这个意思。

是的，是约定俗成的。

应用层http协议的method,比如吃饭用筷子吃，勺子吃，叉子吃。

协议就是这样定的，协议的意思就是一个约定。
如果自己实现客户端服务端，当然可以不管这些约定；不过如果做一些对接，对方恪守约定的情况下，你不守约是不会让你通过的。

这是一个提倡和标准。严格反对滥用。 移动APP和网站都是数据驱动型的上层应用，通信严重依赖于http协议，所以我会建议大家尽可能的了解get和post的区别，不仅仅是一个约定而是一个标准规则。凡是涉及到修改 删除创建操作，不能使用get，差异性还有其他方面，这是其中最重要的一个前提。说深一点，这是专业能力的提现。

打个比方，如果你的前后端用cookie保存状态，而你又使用get来添加或者修改数据，辣么，csrf会把你的网站日翻= =