GET請(qǐng)求 | POST請(qǐng)求 |
---|---|
冪等跨晴,不會(huì)產(chǎn)生副作用(在瀏覽器刷新/回退時(shí)是無(wú)害的)兼犯。在HTTP的定義中乳规,GET被稱為安全方法强衡。 | 非冪等捏膨,重復(fù)請(qǐng)求可能會(huì)帶來(lái)意想不到的效果。 在HTTP的定義中食侮,POST不是安全的方法号涯。 |
GET比POST更不安全,因?yàn)閰?shù)直接暴露在URL上锯七,所以不能用來(lái)傳遞敏感信息链快。 | POST放在Request body中。 |
GET請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽器歷史記錄和服務(wù)器上日志記錄里 | POST參數(shù)都在body里面眉尸,服務(wù)器日志記錄不到域蜗,瀏覽器歷史也記錄不到。 |
GET請(qǐng)求由于瀏覽器地址欄的限制噪猾,對(duì)傳送的參數(shù)是有長(zhǎng)度限制的 | POST沒(méi)有霉祸。 |
GET產(chǎn)生的URL地址可以被Bookmark。 | POST不可以袱蜡。 |
GET請(qǐng)求會(huì)被瀏覽器主動(dòng)cache | POST不會(huì)丝蹭,除非手動(dòng)設(shè)置。 |
GET請(qǐng)求只能進(jìn)行url編碼 | POST支持多種編碼方式坪蚁。 |
對(duì)參數(shù)的數(shù)據(jù)類型奔穿,GET只接受ASCII字符 | POST沒(méi)有限制。 |
GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包 | POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包敏晤。 |
* 1. 冪等的意思是贱田,同一個(gè)請(qǐng)求重復(fù)發(fā)送返回同樣的結(jié)果。
* 2. 如果不使用HTTPS傳輸嘴脾,GET和POST都是不安全的男摧。
Safe
- 安全這里的「安全」和通常理解的「安全」意義不同,如果一個(gè)方法的語(yǔ)義在本質(zhì)上是「只讀」的译打,那么這個(gè)方法就是安全的耗拓。客戶端向服務(wù)端的資源發(fā)起的請(qǐng)求如果使用了是安全的方法扶平,就不應(yīng)該引起服務(wù)端任何的狀態(tài)變化帆离,因此也是無(wú)害的。 此RFC定義结澄,GET, HEAD, OPTIONS 和 TRACE 這幾個(gè)方法是安全的哥谷。但是這個(gè)定義只是規(guī)范,并不能保證方法的實(shí)現(xiàn)也是安全的麻献,服務(wù)端的實(shí)現(xiàn)可能會(huì)不符合方法語(yǔ)義们妥,正如上文說(shuō)過(guò)的使用GET修改用戶信息的情況。引入安全這個(gè)概念的目的是為了方便網(wǎng)絡(luò)爬蟲和緩存勉吻,以免調(diào)用或者緩存某些不安全方法時(shí)引起某些意外的后果监婶。User Agent(瀏覽器)應(yīng)該在執(zhí)行安全和不安全方法時(shí)做出區(qū)分對(duì)待,并給用戶以提示。
Idempotent
- 冪等冪等的概念是指同一個(gè)請(qǐng)求方法執(zhí)行多次和僅執(zhí)行一次的效果完全相同惑惶。按照RFC規(guī)范煮盼,PUT,DELETE和安全方法都是冪等的带污。同樣僵控,這也僅僅是規(guī)范,服務(wù)端實(shí)現(xiàn)是否冪等是無(wú)法確保的鱼冀。引入冪等主要是為了處理同一個(gè)請(qǐng)求重復(fù)發(fā)送的情況报破,比如在請(qǐng)求響應(yīng)前失去連接,如果方法是冪等的千绪,就可以放心地重發(fā)一次請(qǐng)求充易。這也是瀏覽器在后退/刷新時(shí)遇到POST會(huì)給用戶提示的原因:POST語(yǔ)義不是冪等的,重復(fù)請(qǐng)求可能會(huì)帶來(lái)意想不到的后果荸型。
Cacheable
- 可緩存性 顧名思義就是一個(gè)方法是否可以被緩存盹靴,此RFC里GET,HEAD和某些情況下的POST都是可緩存的帆疟,但是絕大多數(shù)的瀏覽器的實(shí)現(xiàn)里僅僅支持GET和HEAD鹉究。關(guān)于緩存的更多內(nèi)容可以去看RFC7234。
另踪宠,參考:https://www.cnblogs.com/nankezhishi/archive/2012/06/09/getandpost.html