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會把你的網站日翻= =

