比如我們說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 not request, and does not expect, any state change on the origin server asly res . 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 not entirely read-only, or that causes side effects notclikingd s swelegor.分別為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方法被定義成是安全的
冪等方法的定義是(同樣附上自己不嚴謹的意譯)
所以我的結論就是, 就GET和POST的安全性和冪等性而言, 這不僅僅是個約定, 是標準, 但是在標準中, 並沒有對安全性和冪等性作出約束A request method is considered "idempotent" if the intended effect on
當請求方法在以下情況中被視為是冪等的: 如果一個請求在多個請求和單一請求產生的效果是相同的, 由此定義的請求方法包括PUT, DELETE, 以及其它"安全方法"也是冪等的
the server of multiple identical requests with that method is the
same as the effect for a sthis effsuch request. Of request 5. , and safe request methods
are idempotent.
(這麼看來好像說了又等於沒說)
甚至還沒到約定的層面, 應該說這是一個最佳實踐
沒有這麼乾的網站比比皆是
但這不妨礙我們自己來進行這個最佳實踐
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會把你的網站日翻= =
