HTTP協定的六種請求方法

拋磚引玉，聊下概念性的東西先：

HTTP協議 （Hyper Text Transfer Protocol）

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

HTTP協議特點

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

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

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

4.簡單快速

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

客戶端請求訊息

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

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

伺服器響應訊息

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

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

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到伺服器即可。這都是協議層面來討論的。 put請求專注於update操作，但是與之相關的是還有這個patch請求，兩者雖然都專注於update操作，但是前者put是全局而言，後者patch是侷限於某一條件或者範圍而言，簡單的說就是兩者的粒度是不同的。

GET 

請求示例

GET https://testrail-tools.trendmicro.com/portal/admin/getTimerInitStatus HTTP/1.1    
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
Referer: https://testrail-tools.trendmicro.com/portal/admin/toLicenseTimerConfig?id=7
Accept-Language: zh-CN
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: testrail-tools.trendmicro.com
Connection: Keep-Alive
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儲存起來，每次請求攜帶上認證資訊。這部份以後再聊吧。    

響應示例

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Wed, 31 Dec 1969 16:00:00 PST
X-Application-Context: application:prod
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 20 Jun 2018 15:00:16 GMT

{"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

請求示例

POST https://testrail-tools.trendmicro.com/portal/admin/editTimer HTTP/1.1
Host: testrail-tools.trendmicro.com
Connection: keep-alive
Content-Length: 35
Accept: application/json, text/javascript, */*; q=0.01
Origin: https://testrail-tools.trendmicro.com
X-Requested-With: XMLHttpRequest
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
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: https://testrail-tools.trendmicro.com/portal/admin/toAdminTimerConfig?id=7
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: _ga=GA1.2.199305797.1501211992; _ga=GA1.1.199305797.1501211992; _gid=GA1.2.56449187.1529562439; _gat_gtag_UA_111346521_2=1

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行 請求資料

響應示例

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Application-Context: application:prod
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 21 Jun 2018 07:36:58 GMT

{"result":"edit timer success"}

其他這裡就不累述了。

說了這麼多，這麼多請求方式都是http協議的標準，你完全可以隨心所欲，全部用post或者全部用get，但是你要是開發的是商業產品，那你就要為你自己的隨便買單咯。

好比刪除一樣東西，如果用get請求方式：http:/xxx/delete?id=1,那你很快就知道，這些標準也能讓其他人一眼就能知道具體所要做的意思。 

結束語：其實我們大部分情況下只用到了GET和POST。如果想設計一個符合RESTful規範的web應用程式，則這六種方法都會用到。不過即使暫時不想涉及REST，

瞭解這六種方法的本質仍然是很有作用的。大家將會發現，原來web也是很簡潔明瞭的。下面再次依次說明這六種方法。