前言：從來沒想過要寫關於http協議請求方式的，可是今天遇到一位同事，竟然對HTTP的請求方式一點都不瞭解，所以決定總結一下，也記錄一下。

HTTP協議 （Hyper Text Transfer Protocol）

HTTP是一個基於TCP/IP通訊協議來傳遞資料，包括html檔案、影象、結果等，即是一個客戶端和伺服器端請求和應答的標準。

HTTP協議特點

1.http無連線：限制每次連線只處理一個請求，服務端完成客戶端的請求後，即斷開連線。（傳輸速度快，減少不必要的連線，但也意味著每一次訪問都要建立一次連線，效率降低）

2.http無狀態：對於事務處理沒有記憶能力。每一次請求都是獨立的，不記錄客戶端任何行為。（優點解放伺服器，但可能每次請求會傳輸大量重複的內容資訊）

3.客戶端/服務端模型：客戶端支援web瀏覽器或其他任何客戶端，伺服器通常是apache或者iis等

4.簡單快速

5.靈活：可以傳輸任何型別的資料

客戶端請求訊息

客戶端傳送一個請求到伺服器的請求訊息包括以下格式：

    請求行，請求頭部，空行，請求資料 （圖片來自網路）

伺服器響應訊息

伺服器響應包括如下格式：

    狀態行，訊息報頭，空行，響應正文 

HTTP 請求方法

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五種請求方法：PUT, DELETE,CONNECT,OPTIONS 和 TRACE 方法

用於特定請求的方式還有幾種：

GET 和 POST 比較

注意：以上只是一種規範，如果非要給get加上request body，或者給post的url上帶上引數，技術上沒有任何問題。

另外曾經看到一篇文章聽說『99% 的人都理解錯了 HTTP 中 GET 與 POST 的區別』？？說，get傳送1個tcp包，而post傳送兩個tcp包，後來被驗證這個說法是不正確的，其實get如果也傳送body，則也會發送Expect:100。

PATCH 和 PUT 比較

注意：比如更新一個userinfo，包含name,age,sex等多個欄位，如果只修改了age，如果用put來更新，則需要把其他沒有變更的也要提交到伺服器，但是使用patch，則只需要提交age到伺服器即可。這都是協議層面來討論的。

GET 

請求示例

1. GET https://testrail-tools.trendmicro.com/portal/admin/getTimerInitStatus HTTP/1.1

2. Accept: application/json, text/javascript, */*; q=0.01

3. X-Requested-With: XMLHttpRequest

4. Referer: https://testrail-tools.trendmicro.com/portal/admin/toLicenseTimerConfig?id=7

5. Accept-Language: zh-CN

6. Accept-Encoding: gzip, deflate

7. User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

8. Host: testrail-tools.trendmicro.com

9. Connection: Keep-Alive

10. Cookie: _ga=GA1.2.1909963682.1524537669; _gid=GA1.2.563928490.1529501401

以上對應

第1行 請求行

    請求方法（get）+空格+url(https://testrail-tools.trendmicro.com/portal/admin/getTimerInitStatus)+空格+協議版本（HTTP/1.1）

第2-10都是請求頭部

   Accept：表示客戶端接受的內容型別，按照先後順序表示客戶端接收資料的先後次序

    X-Requested-With：以x開頭的是非http標準，一般是某種技術的出現而定義的；這裡是用來判斷是http請求還是ajax請求。

    Referer：從這個頁面訪問請求行裡的url

    Accept-Language：客戶端接受內容返回優先選擇的語言

    Accept-Encoding：客戶端可以接受的伺服器對返回內容進行編碼壓縮的格式。

    User-Agent：客戶端執行的瀏覽器型別資訊。

    Host：頭域指定請求的伺服器的地址和埠，HTTP/1.1必須包括Host，否則返回400

    Connection：表示是否需要持久連線。如果web伺服器端看到這裡的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1預設進行持久連線），它就可以利用持久連線的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點， web伺服器需要在返回給客戶端HTTP頭資訊中傳送一個Content-Length（返回資訊正文的長度）頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然 後在正式寫出內容之前計算它的大小。

    Cookie：http請求時，會把儲存的cookie也傳送伺服器。cookie是儲存在客戶端裡的，分為記憶體cookie和硬碟cookie。前者隨著瀏覽器關閉而消失，後者由過期時間或者使用者手動清除。因為http請求是無狀態的，所以伺服器為了認證，會生成sessionid，讓瀏覽器setcookie儲存起來，每次請求攜帶上認證資訊。這部份以後再將。(●'◡'●)

響應示例

1. HTTP/1.1 200 OK

2. Server: Apache-Coyote/1.1

3. Cache-Control: private

4. Expires: Wed, 31 Dec 1969 16:00:00 PST

5. X-Application-Context: application:prod

6. Content-Type: application/json;charset=UTF-8

7. Transfer-Encoding: chunked

8. Date: Wed, 20 Jun 2018 15:00:16 GMT

9. {"advancewarn":"1","userstatus":"1","ldap":"1","licensealarm":"1","deltempzipfile":"1","sctmlicense":"0","user":"1"}

第1行 狀態行

第2-8 訊息報頭

    Server：包含處理請求的伺服器資訊，包含多個產品註釋和標識。

    Cache-Control：告知快取機制是否可以快取和型別，private是隻能當前使用者，不能被共享。

    Expires：響應過期時間

    X-Application-Context：application配置，這裡表示讀取的是application-prod.properties

    Content-Type：返回資料的型別和字元編碼格式

    Transfer-Encoding：告知接收端，報文采取了何種編碼，chunked表示伺服器無法確定訊息大小，一般比如下載等，就採用chunked。

    Date：返回訊息的時間

第 9 行 空行

第 10 行 響應正文

    訊息報頭指定了是返回json字串。

POST

請求示例

1. POST https://testrail-tools.trendmicro.com/portal/admin/editTimer HTTP/1.1

2. Host: testrail-tools.trendmicro.com

3. Connection: keep-alive

4. Content-Length: 35

5. Accept: application/json, text/javascript, */*; q=0.01

6. Origin: https://testrail-tools.trendmicro.com

7. X-Requested-With: XMLHttpRequest

8. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36

9. Content-Type: application/x-www-form-urlencoded; charset=UTF-8

10. Referer: https://testrail-tools.trendmicro.com/portal/admin/toAdminTimerConfig?id=7

11. Accept-Encoding: gzip, deflate, br

12. Accept-Language: zh-CN,zh;q=0.9

13. Cookie: _ga=GA1.2.199305797.1501211992; _ga=GA1.1.199305797.1501211992; _gid=GA1.2.56449187.1529562439; _gat_gtag_UA_111346521_2=1

14. type=del&interval=1200&timelag=7200

第1行同 get

第2-13 行 請求頭部

    Content-Length：告知伺服器，請求資料的大小

    Origin：origin類似refered，但比refered更人性化，origin只出現在post中，而origin也不攜帶敏感資訊和具體url路徑。

    Content-Type：http請求提交內容的編碼型別，一般只有post需要設定。application/x-www-form-urlencoded（預設）和multipart/form-data。

第14行 空行

第15行 請求資料

響應示例

1. HTTP/1.1 200 OK

2. Server: Apache-Coyote/1.1

3. X-Application-Context: application:prod

4. Content-Type: application/json;charset=UTF-8

5. Transfer-Encoding: chunked

6. Date: Thu, 21 Jun 2018 07:36:58 GMT

7. {"result":"edit timer success"}

其他這裡就不累述了。

說了這麼多，這麼多請求方式都是http協議的標準，你完全可以隨心所欲，全部用post或者全部用get，但是你要是開發的是商業產品，那你就要為你自己的隨便買單咯。好比刪除一樣東西，如果用get請求方式：http:/xxxx/delete?id=123,那你很快就知道，啥叫自作孽不可活。另外這些標準也能讓其他人一眼就能知道具體所要做的意思。

HTTP狀態碼

注：