GET和POST請求有什么區別

本篇文章為大家展示了GET和POST請求有什么區別，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

有沒有簡單的答案？

有的，我們萬能的w3schools可以看到答案，英文點這里，中文點這里可以看到原始的網頁。

這個就是我們常說的GET和POST了。但是這并不是真正的GET和POST協議，而是我們常用瀏覽器（部分瀏覽器不一樣）的封裝后的樣子。所以我也想聊一下關于瀏覽器和協議對HTTP通訊協議封裝的區別。

簡單總結一下GET和POST

協議與方法

GET和POST都是基于HTTP協議。在計算機網絡7層的協議模型中，HTTP協議是隸屬于最高層應用層的。也是一種基于第四層傳輸層TCP/IP協議的。這也導致了本質上GET和POST這兩種請求其實是沒有太大的區別的。區別只是請求的報文格式不一樣而已。 如果我們把這兩種請求用最短的方式，沒有任何參數的展現成HTTP報文信息，其實就沒有什么太大區別了，如下

GET /test HTTP/1.1
Host: localhost:8080

POST /test HTTP/1.1
Host: localhost:8080

設計初衷和應用

GET是為了獲得信息從服務器到本地，POST是為了推送信息從本地到服務器，行為上是兩種截然相反的操作。

由于GET方法的目的就是為了獲取信息，當我們假設如果數據庫的數據不變，請求的參數不變（基于當前時間的參數，應當認為請求參數是變化的，比如last_5_minutes），那么我們返回的結果也應該是不變的。反復的讀取數據庫中的數據，不應該對數據本身產生副作用（統計信息除外）。所以我們說GET是符合冪等性（idempotent）。因此可以被瀏覽器與其他客戶端緩存。

POST方法的目的是創建資源，即使我們請求的參數不變，但是對數據庫而言都是要創建一個新的記錄，雖然所有的數值都和前面的一樣，但是這也是可以合理存在的，只是在數據庫中主鍵不同罷了。這樣的創建流程對數據庫的數據有實質影響，每創建一次就多一條數據。因此我們說POST是不符合冪等性的。因此也不可以被緩存。試想一下，如果POST請求可以被緩存，我們想在電商網站買東西，前后下單2次，都是一樣的東西。POST返回的信息是直接掃描本地緩存，直接返回第一次的下的成功，并沒有進行第二次的下單提交。或者如果可以用書簽保存鏈接，是不是點一次書簽查看就下了一次訂單？此外在發出POST請求后，有些頁面刷新的時候回彈出窗口 “確認重新提交表單”。這些都是POST不能被緩存的原因了。

但是如果說到實際使用，也不是不可以交換功能。畢竟都是使用相同的協議。所以我可以設計一個API，用GET方法的請求來插入數據，用POST方法的請求來返回查詢數據。也許用POST方法請求數據還能理解，但是堅決不推薦用GET方法來插入數據，這樣做只會徒增維護難度。

瀏覽器中與RESTful接口規范中的封裝對比

很多人共同的疑問

1. GET請求中是否可以帶body？

我們先來看看在1999年6月的RFC2616-4.3HTTP協議1.1中第33頁提及到內容如下：

A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

然而RFC2616-4.3已經過時了，推出了新的修正RFC7230-3.3。但是問題是最新的規范居然是更加寬松？我對此表示很無奈。

我們再來看看在2014年6月的RFC7230-3.3HTTP協議1.1消息語法和轉發中第28頁提及到內容如下：

The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field. Request message framing is independent of method semantics, even if the method does not define any use for a message body.

所以從現在最新的協議來看，攜帶body信息已經無所謂使用的是什么方法了。但是我真的建議在GET請求中不要帶body。

2. GET請求有沒有長度限制？

首先我們要明確的是我們經常說的GET請求長度限制是之URI請求長度限制。

我們先來看看在1999年6月的RFC2616-3.2.1

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs.

我們再來看看2014年6月的RFC7230-2.5HTTP協議1.1消息語法和轉發中第13頁提及到內容如下：

HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate will vary widely, depending on the deployment context and purpose of the implementation.

我們同樣來看看2014年6月的RFC7230-3.1.1HTTP協議1.1消息語法和轉發中第21頁提及到內容如下：

HTTP does not place a predefined limit on the length of a request-line, as described in Section 2.5. A server that receives a method longer than any that it implements SHOULD respond with a 501(Not Implemented) status code. A server that receives a request-target longer than any URI it wishes to parse MUST respond with a 414 (URI Too Long) status code (see Section 6.5.12 of [RFC7231]).

這就是HTTP協議規范里的要求，從來沒有要求過URI的長度限制，但是為什么我們會有URL長度限制的問題呢？ 我們再來看看微軟谷歌等大廠的規范

微軟 IE瀏覽器的規范

Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs.

Google Chrome瀏覽器的規范

In general, the web platform does not have limits on the length of URLs (although 2^31 is a common limit). Chrome limits URLs to a maximum length of 2MB for practical reasons and to avoid causing denial-of-service problems in inter-process communication.

所以現在我們現在知道URI長度限制只是各個瀏覽器廠商自己的限制，且限制還不統一。而HTTP規范根本就沒有規定最長長度限制，也就是說看你的服務器自己決定吧。

3. POST方法是否比GET方法更安全？（這不是HTTP規范限定的東西）

網上很多人都說POST方法比GET方法更安全，主要是POST數據部分不直接暴露在URL上，而GET的參數全都在URL上，更容易看到。但是，從傳輸數據上來看，他們都是明文傳輸，每次請求和返回的字節都會以明文的形式在網上傳輸。如果想要安全傳輸，通用的做法是使用SSL協議來加密，也就是業界的標準規范HTTPS。當然HTTP協議和SSL協議是兩個獨立的協議。如果你有幸參與一些特殊項目，那么HTTP可能就不是用SSL協議加密了，也許會換成國密SM協議，參見國密標準網密碼標準應用指南。

所以在網上傳輸數據如果想要更安全，一定要用HTTPS協議。但在網頁設計上，決定不能把密碼密鑰一類的東西用URL傳輸，畢竟還是有可能使用者被身后的人偷窺到URL上的信息。

4. POST方法一次請求會發送兩個TCP數據包？（這不是HTTP規范限定的東西）

網上很多人說GET方式的請求，瀏覽器會把請求HEADER和參數一并發送出去，服務端響應200，請求成功。而POST方式的請求，瀏覽器會先發送HEADER給服務器，服務器響應代碼100 continue，瀏覽器再發送一個DATA給服務器，服務器響應200，請求成功。

然而這也只是說瀏覽器會這樣做，并不是HTTP協議中的規范。這一點和我們剛才提到的URI的長度一樣，都是由各個瀏覽器廠商所制定的規則。我們假設一下，如果GET方法的URL太長一個TCP包放不下怎么辦，那是不是GET也要發2個TCP包？而且FireFox瀏覽器針對POST的小數據發送也是一個TCP包，這又怎么解釋？所以最合理的方法就是依據瀏覽器和客戶端的自身規則而定。

如果數據量很小，1次TCP包和2次TCP包沒有太大的時間差。如果數據量很大，通常POST請求不是一次TCP包能包含所有的。應該會有很多的TCP包。如果先發一個HEAD過去，如果服務器沒有回應，那么數據包的部分就可以不發送了。但服務器都響應失敗了，你還在乎是否發送1次還是2次？

回到文章標題，再換一種說法，如果有人問你GET和POST的區別，我們來回答發送1次還是2次TCP包的問題，你覺得你用傳輸層協議（TCP）的答案能回答應用層協議（HTTP）的問題？

上述內容就是GET和POST請求有什么區別，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。