GET 和 POST 到底有什麼區別?

裡的url帶querystring就行。只不過表單裡面的那些用 等標籤經過用戶操作產生的數據都在會在body裡。

因此我們一般會泛泛的說“GET請求沒有body,只有url,請求數據放在url的querystring中;POST請求的數據在body中“。但這種情況僅限於瀏覽器發請求的場景。

接口中的GET和POST

這裡是指通過瀏覽器的Ajax api,或者iOS/Android的App的http client,java的commons-httpclient/okhttp或者是curl,postman之類的工具發出來的GET和POST請求。此時GET/POST不光能用在前端和後端的交互中,還能用在後端各個子服務的調用中(即當一種RPC協議使用)。儘管RPC有很多協議,比如thrift,grpc,但是http本身已經有大量的現成的支持工具可以使用,並且對人類很友好,容易debug。HTTP協議在微服務中的使用是相當普遍的。

當用HTTP實現接口發送請求時,就沒有瀏覽器中那麼多限制了,只要是符合HTTP格式的就可以發。HTTP請求的格式,大概是這樣的一個字符串(為了美觀,我在\\r\\n後都換行一下):

HTTP/1.1\\r\\n : \\r\\n : \\r\\n ... : \\r\\n \\r\\n

其中的“"可以是GET也可以是POST,或者其他的HTTP Method,如PUT、DELETE、OPTION……。從協議本身看,並沒有什麼限制說GET一定不能沒有body,POST就一定不能把參放到的querystring上。因此其實可以更加自由的去利用格式。比如Elastic Search的_search api就用了帶body的GET;也可以自己開發接口讓POST一半的參數放在url的querystring裡,另外一半放body裡;你甚至還可以讓所有的參數都放Header裡——可以做各種各樣的定製,只要請求的客戶端和服務器端能夠約定好。

當然,太自由也帶來了另一種麻煩,開發人員不得不每次討論確定參數是放url的path裡,querystring裡,body裡,header裡這種問題,太低效了。於是就有了一些列接口規範/風格。其中名氣最大的當屬REST。REST充分運用GET、POST、PUT和DELETE,約定了這4個接口分別獲取、創建、替換和刪除“資源”,REST最佳實踐還推薦在請求體使用json格式。這樣僅僅通過看HTTP的method就可以明白接口是什麼意思,並且解析格式也得到了統一。

json相對於x-www-form-urlencoded的優勢在於1)可以有嵌套結構;以及 2)可以支持更豐富的數據類型。通過一些框架,json可以直接被服務器代碼映射為業務實體。用起來十分方便。但是如果是寫一個接口支持上傳文件,那麼還是multipart/form-data格式更合適。

REST中GET和POST不是隨便用的。在REST中, 【GET】 + 【資源定位符】被專用於獲取資源或者資源列表,比如:

GET http://foo.com/books 獲取書籍列表 GET http://foo.com/books/:bookId 根據bookId獲取一本具體的書

與瀏覽器的場景類似,REST GET也不應該有副作用,於是可以被反覆無腦調用。瀏覽器(包括瀏覽器的Ajax請求)對於這種GET也可以實現緩存(如果服務器端提示了明確需要Caching);但是如果用非瀏覽器,有沒有緩存完全看客戶端的實現了。當然,也可以從整個App角度,也可以完全繞開瀏覽器的緩存機制,實現一套業務定製的緩存框架。

GET 和 POST 到底有什麼區別?

okhttp中控制Cache的類

REST 【POST】+ 【資源定位符】則用於“創建一個資源”,比如:

POST http://foo.com/books { "title": "大寬寬的碎碎念", "author": "大寬寬", ... }

這裡你就能留意到瀏覽器中用來實現表單提交的POST,和REST裡實現創建資源的POST語義上的不同。

順便講下REST POST和REST PUT的區別。有些api是使用PUT作為創建資源的Method。PUT與POST的區別在於,PUT的實際語義是“replace”replace。REST規範裡提到PUT的請求體應該是完整的資源,包括id在內。比如上面的創建一本書的api也可以定義為:

PUT http://foo.com/books { "id": "BOOK:affe001bbe0556a", "title": "大寬寬的碎碎念", "author": "大寬寬", ... }

服務器應該先根據請求提供的id進行查找,如果存在一個對應id的元素,就用請求中的數據整體替換已經存在的資源;如果沒有,就用“把這個id對應的資源從【空】替換為【請求數據】“。直觀看起來就是“創建”了。

與PUT相比,POST更像是一個“factory”,通過一組必要的數據創建出完整的資源。

至於到底用PUT還是POST創建資源,完全要看是不是提前可以知道資源所有的數據(尤其是id),以及是不是完整替換。比如對於AWS S3這樣的對象存儲服務,當想上傳一個新資源時,其id就是“ObjectName”可以提前知道;同時這個api也總是完整的replace整個資源。這時的api用PUT的語義更合適;而對於那些id是服務器端自動生成的場景,POST更合適一些。

有點跑題,就此打住。

GET 和 POST 到底有什麼區別?

AWS S3 創建一個Object的API描述

回到接口這個主題,上面僅僅粗略介紹了REST的情況。但是現實中總是有REST的變體,也可能用非REST的協議(比如JSON-RPC、SOAP等),每種情況中的GET和POST又會有所不同。

關於安全性

我們常聽到GET不如POST安全,因為POST用body傳輸數據,而GET用url傳輸,更加容易看到。但是從攻擊的角度,無論是GET還是POST都不夠安全,因為HTTP本身是明文協議每個HTTP請求和返回的每個byte都會在網絡上明文傳播,不管是url,header還是body。這完全不是一個“是否容易在瀏覽器地址欄上看到“的問題。

為了避免傳輸中數據被竊取,必須做從客戶端到服務器的端端加密。業界的通行做法就是https——即用SSL協議協商出的密鑰加密明文的http數據。這個加密的協議和HTTP協議本身相互獨立。如果是利用HTTP開發公網的站點/App,要保證安全,https是最最基本的要求。

當然,端端加密並不一定非得用https。比如國內金融領域都會用私有網絡,也有GB的加密協議SM系列。但除了軍隊,金融等特殊機構之外,似乎並沒有必要自己發明一套類似於ssl的協議。

回到HTTP本身,的確GET請求的參數更傾向於放在url上,因此有更多機會被洩漏。比如攜帶私密信息的url會展示在地址欄上,還可以分享給第三方,就非常不安全了。此外,從客戶端到服務器端,有大量的中間節點,包括網關,代理等。他們的access log通常會輸出完整的url,比如nginx的默認access log就是如此。如果url上攜帶敏感數據,就會被記錄下來。但請注意,就算私密數據在body裡,也是可以被記錄下來的,因此如果請求要經過不信任的公網,避免洩密的唯一手段就是https。這裡說的“避免access log洩漏“僅僅是指避免可信區域中的http代理的默認行為帶來的安全隱患。比如你是不太希望讓自己公司的運維同學從公司主網關的log裡看到用戶的密碼吧。

GET 和 POST 到底有什麼區別?

另外,上面講過,如果是用作接口,GET實際上也可以帶body,POST也可以在url上攜帶數據。所以實際上到底怎麼傳輸私密數據,要看具體場景具體分析。當然,絕大多數場景,用POST + body裡寫私密數據是合理的選擇。一個典型的例子就是“登錄”:

POST http://foo.com/user/login { "username": "dakuankuan", "passowrd": "12345678" }

安全是一個巨大的主題,有由很多細節組成的一個完備體系,比如返回私密數據的mask,XSS,CSRF,跨域安全,前端加密,釣魚,salt,…… POST和GET在安全這件事上僅僅是個小角色。因此單獨討論POST和GET本身哪個更安全意義並不是太大。只要記得一般情況下,私密數據傳輸用POST + body就好。

關於編碼

常見的說法有,比如GET的參數只能支持ASCII,而POST能支持任意binary,包括中文。但其實從上面可以看到,GET和POST實際上都能用url和body。因此所謂編碼確切地說應該是http中url用什麼編碼,body用什麼編碼。

先說下url。url只能支持ASCII的說法源自於RFC1738

Thus, only alphanumerics, the special characters "$-_.+!*'(),", and

reserved characters used for their reserved purposes may be used

unencoded within a URL.

實際上這裡規定的僅僅是一個ASCII的子集[a-zA-Z0-9$-_.+!*'(),]。它們是可以“不經編碼”在url中使用。比如儘管空格也是ASCII字符,但是不能直接用在url裡。

那這個“編碼”是什麼呢?如果有了特殊符號和中文怎麼辦呢?一種叫做percent encoding的編碼方法就是幹這個用的:

https://en.wikipedia.org/wiki/Percent-encoding​en.wikipedia.org

這也就是為啥我們偶爾看到url裡有一坨%和16位數字組成的序列。

使用Percent Encoding,即使是binary data,也是可以通過編碼後放在URL上的。

GET 和 POST 到底有什麼區別?

但要特別注意,這個編碼方式只管把字符轉換成URL可用字符,但是卻不管字符集編碼(比如中文到底是用UTF8還是GBK)這塊早期一直都相當亂,也沒有什麼統一規範。比如有時跟網頁編碼一樣,有的是操作系統的編碼一樣。最要命的是瀏覽器的地址欄是不受開發者控制的。這樣,對於同樣一個帶中文的url,如果有的瀏覽器一定要用GBK(比如老的IE8),有的一定要用UTF8(比如chrome)。後端就可能認不出來。對此常用的辦法是避免讓用戶輸入這種帶中文的url。如果有這種形式的請求,都改成用戶界面上輸入,然後通過Ajax發出的辦法。Ajax發出的編碼形式開發者是可以100%控制的。

不過目前基本上utf8已經大一統了。現在的開發者除非是被國家規定要求一定要用GB系列編碼的場景,基本上不會再遇到這類問題了。

關於url的編碼,阮一峰的一篇文章有比較詳細的解釋:

關於URL編碼 - 阮一峰的網絡日誌​www.ruanyifeng.com

GET 和 POST 到底有什麼區別?

順便說一句,儘管在瀏覽器地址欄可以看到中文。但這種url在發送請求過程中,瀏覽器會把中文用字符編碼+Percent Encode翻譯為真正的url,再發給服務器。瀏覽器地址欄裡的中文只是想讓用戶體驗好些而已。

再討論下Body。HTTP Body相對好些,因為有個Content-Type來比較明確的定義。比如:

POST xxxxxx HTTP/1.1 ... Content-Type: application/x-www-form-urlencoded ; charset=UTF-8

這裡Content-Type會同時定義請求body的格式(application/x-www-form-urlencoded)和字符編碼(UTF-8)。

所以body和url都可以提交中文數據給後端,但是POST的規範好一些,相對不容易出錯,容易讓開發者安心。對於GET+url的情況,只要不涉及到在老舊瀏覽器的地址欄輸入url,也不會有什麼太大的問題。

回到POST,瀏覽器直接發出的POST請求就是表單提交,而表單提交只有application/x-www-form-urlencoded針對簡單的key-value場景;和multipart/form-data,針對只有文件提交,或者同時有文件和key-value的混合提交表單的場景。

如果是Ajax或者其他HTTP Client發出去的POST請求,其body格式就非常自由了,常用的有json,xml,文本,csv……甚至是你自己發明的格式。只要前後端能約定好即可。

瀏覽器的POST需要發兩個請求嗎?

上文中的"HTTP 格式“清楚的顯示了HTTP請求可以被大致分為“請求頭”和“請求體”兩個部分。使用HTTP時大家會有一個約定,即所有的“控制類”信息應該放在請求頭中,具體的數據放在請求體裡“。於是服務器端在解析時,總是會先完全解析全部的請求頭部。這樣,服務器端總是希望能夠了解請求的控制信息後,就能決定這個請求怎麼進一步處理,是拒絕,還是根據content-type去調用相應的解析器處理數據,或者直接用zero copy轉發。

比如在用Java寫服務時,請求處理代碼總是能從HttpSerlvetRequest裡getParameter/Header/url。這些信息都是請求頭裡的,框架直接就解析了。而對於請求體,只提供了一個inputstream,如果開發人員覺得應該進一步處理,就自己去讀取和解析請求體。這就能體現出服務器端對請求頭和請求體的不同處理方式。

舉個實際的例子,比如寫一個上傳文件的服務,請求url中包含了文件名稱,請求體中是個尺寸為幾百兆的壓縮二進制流。服務器端接收到請求後,就可以先拿到請求頭部,查看用戶是不是有權限上傳,文件名是不是符合規範等。如果不符合,就不再處理請求體的數據了,直接丟棄。而不用等到整個請求都處理完了再拒絕。

為了進一步優化,客戶端可以利用HTTP的Continued協議來這樣做:客戶端總是先發送所有請求頭給服務器,讓服務器校驗。如果通過了,服務器回覆“100 - Continue”,客戶端再把剩下的數據發給服務器。如果請求被拒了,服務器就回復個400之類的錯誤,這個交互就終止了。這樣,就可以避免浪費帶寬傳請求體。但是代價就是會多一次Round Trip。如果剛好請求體的數據也不多,那麼一次性全部發給服務器可能反而更好。

基於此,客戶端就能做一些優化,比如內部設定一次POST的數據超過1KB就先只發“請求頭”,否則就一次性全發。客戶端甚至還可以做一些Adaptive的策略,統計發送成功率,如果成功率很高,就總是全部發等等。不同瀏覽器,不同的客戶端(curl,postman)可以有各自的不同的方案。不管怎樣做,優化目的總是在提高數據吞吐和降低帶寬浪費上做一個折衷。

因此到底是發一次還是發N次,客戶端可以很靈活的決定。因為不管怎麼發都是符合HTTP協議的,因此我們應該視為這種優化是一種實現細節,而不用扯到GET和POST本身的區別上。更不要當個什麼世紀大發現。

到底什麼算請求體

看完了上面的內容後,讀者也許會對“什麼是請求體”感到困惑不已,比如x-www-form-endocded編碼的body算不算“請求體”呢?

從HTTP協議的角度,“請求頭”就是Method + URL(含querystring)+ Headers;再後邊的都是請求體。

但是從業務角度,如果你把一次請求立即為一個調用的話。比如上面的

POST http://foo.com/books { "title": "大寬寬的碎碎念", "author": "大寬寬", ... }

用Java寫大概等價於

createBook("大寬寬的碎碎念", "大寬寬");

那麼這一行函數名和兩個參數都可以看作是一個請求,不區分頭和體。即便用HTTP協議實現,title和author編碼到了HTTP請求體中。Java的HttpServletRequest支持用getParameter方法獲取x-www-url-form-encoded中的數據,表達的意思就是“請求“的”參數“。

對於HTTP,需要區分【頭】和【體】,Http Request和Http Response都這麼區分。Http這麼幹主要用作

  • 對於HTTP代理
    • 支持轉發規則,比如nginx先要解析請求頭,拿到URL和Header才能決定怎麼做(轉發proxy_pass,重定向redirect,rewrite後重新判斷……)
    • 需要用請求頭的信息記錄log。儘管請求體裡的數據也可以記錄,但一般只記錄請求頭的部分數據。
    • 如果代理規則不涉及到請求體,那麼請求體就可以不用從內核態的page cache複製一份到用戶態了,可以直接zero copy轉發。這對於上傳文件的場景極為有效。
    • ……
  • 對於HTTP服務器
    • 可以通過請求頭進行ACL控制,比如看看Athorization頭裡的數據是否能讓認證通過
    • 可以做一些攔截,比如看到Content-Length裡的數太大,或者Content-Type自己不支持,或者Accept要求的格式自己無法處理,就直接返回失敗了。
    • 如果body的數據很大,利用Stream API,可以方便支持一塊一塊的處理數據,而不是一次性全部讀取出來再操作,以至於佔用大量內存。
    • ……

但從高一級的業務角度,我們在意的其實是【請求】和【返回】。當我們在說“請求頭”這三個字時,也許實際的意思是【請求】。而用HTTP實現【請求】時,可能僅僅用到【HTTP的請求頭】(比如大部分GET請求),也可能是【HTTP請求頭】+【HTTP請求體】(比如用POST實現一次下單)。

總之,這裡有兩層,不要混哦。

關於URL的長度

因為上面提到了不論是GET和POST都可以使用URL傳遞數據,所以我們常說的“GET數據有長度限制“其實是指”URL的長度限制“。

HTTP協議本身對URL長度並沒有做任何規定。實際的限制是由客戶端/瀏覽器以及服務器端決定的。

先說瀏覽器。不同瀏覽器不太一樣。比如我們常說的2048個字符的限制,其實是IE8的限制。並且原始文檔的說的其實是“URL的最大長度是2083個字符,path的部分最長是2048個字符“。見https://support.microsoft.com/en-us/help/208427/maximum-url-length-is-2-083-characters-in-internet-explorer。IE8之後的IE URL限制我沒有查到明確的文檔,但有些資料稱IE 11的地址欄只能輸入法2047個字符,但是允許用戶點擊html裡的超長URL。我沒實驗,哪位有興趣可以試試。

GET 和 POST 到底有什麼區別?

Chrome的URL限制是2MB,見https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_display_guidelines/url_display_guidelines.md

GET 和 POST 到底有什麼區別?

Safari,Firefox等瀏覽器也有自己的限制,但都比IE大的多,這裡就不挨個列出了。

然而新的IE已經開始使用Chrome的內核了,也就意味著“瀏覽器端URL的長度限制為2048字符”這種說法會慢慢成為歷史。

其他的客戶端,比如Java的,js的http client大多數也並沒有限制URL最大有多長。

除了瀏覽器,服務器這邊也有限制,比如apache的LimieRequestLine指令。

GET 和 POST 到底有什麼區別?

apache實際上限制的是HTTP請求第一行“Request Line“的長度,即 那一行。

再比如nginx用large_client_header_buffers 指令來分配請求頭中的很長數據的buffer。這個buffer可以用來處理url,header value等。

GET 和 POST 到底有什麼區別?

Tomcat的限制是web.xml裡maxHttpHeaderSize來設置的,控制的是整個“請求頭”的總長度。

GET 和 POST 到底有什麼區別?

為啥要限制呢?如果寫過解析一段字符串的代碼就能明白,解析的時候要分配內存。對於一個字節流的解析,必須分配buffer來保存所有要存儲的數據。而URL這種東西必須當作一個整體看待,無法一塊一塊處理,於是就處理一個請求時必須分配一整塊足夠大的內存。如果URL太長,而併發又很高,就容易擠爆服務器的內存;同時,超長URL的好處並不多,我也只有處理老系統的URL時因為不敢碰原來的邏輯,又得追加更多數據,才會使用超長URL。

對於開發者來說,使用超長的URL完全是給自己埋坑,需要同時要考慮前後端,以及中間代理每一個環節的配置。此外,超長URL會影響搜索引擎的爬蟲,有些爬蟲甚至無法處理超過2000個字節的URL。這也就意味著這些URL無法被搜到,坑爹啊。

其實並沒有太大必要弄清楚精確的URL最大長度限制。我個人的經驗是,只要某個要開發的資源/api的URL長度有可能達到2000個bytes以上,就必須使用body來傳輸數據,除非有特殊情況。至於到底是GET + body還是POST + body可以看情況決定。

留意,1個漢字字符經過UTF8編碼 + percent encoding後會變成9個字節,別算錯哦。

總結

上面講了一大堆,是希望讀者不要死記硬背GET和POST的區別,而是能從更廣的層面去看待和思考這個問題。

最後,協議都是人定的。只要客戶端和服務器能彼此認同,就能工作。在常規的情況下,用符合規範的方式去實現系統可以減少很多工作量——大家都約定好了,就不要折騰了。但是,總會有一些情況用常規規範不合適,不滿足需求。這時思路也不能被規範限制死,更不要死摳RFC。這些規範也許不能處理你遇到的特殊問題。比如:

  • Elastic Search的_search接口使用GET,卻用body來表達查詢,因為查詢很複雜,用querystring很麻煩,必須用json格式才舒服,在請求體用json編碼更加容易,不用折騰percent encoding。
  • 用POST寫一個接口下單時可能也要考慮冪等,因為前端可能實現“下單按鍵”有bug,造成用戶一次點擊發出N個請求。你不能說因為POST by design應該是不冪等就不管了。

協議是死的,人是活的。遇到實際的問題時靈活的運用手上的工具滿足需求就好。

"


分享到:


相關文章: