比較常見的http請求
HTTP協(xié)議?（Hyper Text Transfer Protocol）
HTTP是一個基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)，包括html文件、圖像、結果等，即是一個客戶端和服務器端請求和應答的標準。
HTTP協(xié)議特點
1.http無連接：限制每次連接只處理一個請求，服務端完成客戶端的請求后，即斷開連接。（傳輸速度快，減少不必要的連接，但也意味著每一次訪問都要建立一次連接，效率降低）
2.http無狀態(tài)：對于事務處理沒有記憶能力。每一次請求都是獨立的，不記錄客戶端任何行為。（優(yōu)點解放服務器，但可能每次請求會傳輸大量重復的內容信息）
3.客戶端/服務端模型：客戶端支持web瀏覽器或其他任何客戶端，服務器通常是apache或者iis等
4.簡單快速
5.靈活：可以傳輸任何類型的數(shù)據(jù)
客戶端請求消息
客戶端發(fā)送一個請求到服務器的請求消息包括以下格式：
? ? 請求行，請求頭部，空行，請求數(shù)據(jù) （圖片來自網(wǎng)絡）
服務器響應消息
服務器響應包括如下格式：
? ? 狀態(tài)行，消息報頭，空行，響應正文?
?
序號方法描述
1GET發(fā)送請求來獲得服務器上的資源，請求體中不會包含請求數(shù)據(jù)，請求數(shù)據(jù)放在協(xié)議頭中。另外get支持快取、緩存
、可保留書簽等。冪等
2POST和get一樣很常見，向服務器提交資源讓服務器處理，比如提交表單、上傳文件等，可能導致建立新的資源或者對
原有資源的修改。提交的資源放在請求體中。不支持快取。非冪等
3HEAD本質和get一樣，但是響應中沒有呈現(xiàn)數(shù)據(jù)，而是http的頭信息，主要用來檢查資源或超鏈接的有效性或是否可以可達、檢
查網(wǎng)頁是否被串改或更新，獲取頭信息等，特別適用在有限的速度和帶寬下。
4PUT和post類似，html表單不支持，發(fā)送資源與服務器，并存儲在服務器指定位置，要求客戶端事先知
道該位置；比如post是在一個集合上（/province），而put是具體某一個資源上（/province/123）。所以put是安全的，
無論請求多少次，都是在123上更改，而post可能請求幾次創(chuàng)建了幾次資源。冪等
5DELETE請求服務器刪除某資源。和put都具有破壞性，可能被防火墻攔截。如果是https協(xié)議，則無需擔心。冪等
6CONNECTHTTP/1.1協(xié)議中預留給能夠將連接改為管道方式的代理服務器。就是把服務器作為跳板，去訪問其他網(wǎng)頁
然后把數(shù)據(jù)返回回來，連接成功后，就可以正常的get、post了。
7OPTIONS獲取http服務器支持的http請求方法，允許客戶端查看服務器的性能，比如ajax跨域時的預檢等。
8TRACE回顯服務器收到的請求，主要用于測試或診斷。一般禁用，防止被惡意攻擊或盜取信息。
GET 和 POST 比較
?GETPOST
點擊返回/刷新按鈕沒有影響數(shù)據(jù)會重新提交
緩存/添加書簽可以不可以
歷史記錄有沒有
編碼類型application/x-www-form-urlencodedapplication/x-www-form-urlencoded?
或 multipart/form-data。為二進制數(shù)據(jù)使用
多重編碼
是否冪等冪等非冪等
長度限制http協(xié)議沒有限制，但是實際瀏覽器或服務
器有(最大2048)
理論上沒有，可能會收到服務器配置或內存限制
數(shù)據(jù)類型限制只能ASCII，非ascii都要編碼傳輸沒有限制，允許二進制數(shù)據(jù)
安全性數(shù)據(jù)全部展示在url中，不安全相比get，通過request body傳遞數(shù)據(jù)，比較安全
可見效可見不可見
注意：以上只是一種規(guī)范，如果非要給get加上request body，或者給post的url上帶上參數(shù)，技術上沒有任何問題。
另外曾經(jīng)看到一篇文章聽說『99% 的人都理解錯了 HTTP 中 GET 與 POST 的區(qū)別』？？說，get發(fā)送1個tcp包，而post發(fā)送兩個tcp包，后來被驗證這個說法是不正確的，其實get如果也發(fā)送body，則也會發(fā)送Expect:100
PATCH 和 PUT 比較
?PATCHPUT
是否冪等非冪等冪等
粒度局部，最小粒度，節(jié)約網(wǎng)絡帶寬所有
注意：比如更新一個userinfo，包含name,age,sex等多個字段，如果只修改了age，如果用put來更新，則需要把其他沒有變更的也要提交到服務器，但是使用patch，則只需要提交age到服務器即可。這都是協(xié)議層面來討論的。?
GET?
請求示例
GET https://testrail-tools.trendmicro.com/portal/admin/getTimerInitStatus HTTP/1.1Accept: application/json, text/javascript, */*; q=0.01X-Requested-With: XMLHttpRequestReferer: https://testrail-tools.trendmicro.com/portal/admin/toLicenseTimerConfig?id=7Accept-Language: zh-CNAccept-Encoding: gzip, deflateUser-Agent: Mozilla/5.0 (Windows NT10.0; WOW64; Trident/7.0; rv:11.0) like GeckoHost: testrail-tools.trendmicro.comConnection: Keep-AliveCookie: _ga=GA1.2.1909963682.1524537669; _gid=GA1.2.563928490.1529501401
以上對應
第1行 請求行
? ??請求方法（get）+空格+url(https://testrail-tools.trendmicro.com/portal/admin/getTimerInitStatus)+空格+協(xié)議版本（HTTP/1.1）
第2-10都是請求頭部
? ?Accept：表示客戶端接受的內容類型，按照先后順序表示客戶端接收數(shù)據(jù)的先后次序
? ??X-Requested-With：以x開頭的是非http標準，一般是某種技術的出現(xiàn)而定義的；這里是用來判斷是http請求還是ajax請求。
? ??Referer：從這個頁面訪問請求行里的url
? ??Accept-Language：客戶端接受內容返回優(yōu)先選擇的語言
? ??Accept-Encoding：客戶端可以接受的服務器對返回內容進行編碼壓縮的格式。
? ??User-Agent：客戶端運行的瀏覽器類型信息。
? ??Host：頭域指定請求的服務器的地址和端口，HTTP/1.1必須包括Host，否則返回400
? ??Connection：表示是否需要持久連接。如果web服務器端看到這里的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優(yōu)點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現(xiàn)這一點，?web服務器需要在返回給客戶端HTTP頭信息中發(fā)送一個Content-Length（返回信息正文的長度）頭，最簡單的實現(xiàn)方法是：先把內容寫入ByteArrayOutputStream，然?后在正式寫出內容之前計算它的大小。
? ??Cookie：http請求時，會把保存的cookie也發(fā)送服務器。cookie是保存在客戶端里的，分為內存cookie和硬盤cookie。前者隨著瀏覽器關閉而消失，后者由過期時間或者用戶手動清除。因為http請求是無狀態(tài)的，所以服務器為了認證，會生成sessionid，讓瀏覽器setcookie保存起來，每次請求攜帶上認證信息。這部份以后再聊吧。? ??
響應示例
HTTP/1.1200OKServer: Apache-Coyote/1.1Cache-Control: privateExpires: Wed,31 Dec196916:00:00PSTX-Application-Context: application:prodContent-Type: application/json;charset=UTF-8Transfer-Encoding: chunkedDate: Wed,20 Jun201815:00:16GMT{"advancewarn":"1","userstatus":"1","ldap":"1","licensealarm":"1","deltempzipfile":"1","sctmlicense":"0","user":"1"}
第1行 狀態(tài)行
第2-8 消息報頭
? ??Server：包含處理請求的服務器信息，包含多個產品注釋和標識。
? ??Cache-Control：告知緩存機制是否可以緩存和類型，private是只能當前用戶，不能被共享。
? ??Expires：響應過期時間
????X-Application-Context：application配置，這里表示讀取的是application-prod.properties
????Content-Type：返回數(shù)據(jù)的類型和字符編碼格式
????Transfer-Encoding：告知接收端，報文采取了何種編碼，chunked表示服務器無法確定消息大小，一般比如下載等，就采用chunked。
????Date：返回消息的時間
第 9 行 空行
第 10 行 響應正文
? ??消息報頭指定了是返回json字符串。
POST
請求示例
POST https://testrail-tools.trendmicro.com/portal/admin/editTimer HTTP/1.1Host: testrail-tools.trendmicro.comConnection: keep-aliveContent-Length:35Accept: application/json, text/javascript, */*; q=0.01Origin: https://testrail-tools.trendmicro.comX-Requested-With: XMLHttpRequestUser-Agent: Mozilla/5.0 (Windows NT10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36Content-Type: application/x-www-form-urlencoded; charset=UTF-8Referer: https://testrail-tools.trendmicro.com/portal/admin/toAdminTimerConfig?id=7Accept-Encoding: gzip, deflate, brAccept-Language: zh-CN,zh;q=0.9Cookie: _ga=GA1.2.199305797.1501211992; _ga=GA1.1.199305797.1501211992; _gid=GA1.2.56449187.1529562439; _gat_gtag_UA_111346521_2=1type=del&interval=1200&timelag=7200
第1行同 get
第2-13 行 請求頭部
? ??Content-Length：告知服務器，請求數(shù)據(jù)的大小
? ??Origin：origin類似refered，但比refered更人性化，origin只出現(xiàn)在post中，而origin也不攜帶敏感信息和具體url路徑。
? ??Content-Type：http請求提交內容的編碼類型，一般只有post需要設置。application/x-www-form-urlencoded（缺?。┖蚼ultipart/form-data。
第14行 空行
第15行 請求數(shù)據(jù)
響應示例
HTTP/1.1200OKServer: Apache-Coyote/1.1X-Application-Context: application:prodContent-Type: application/json;charset=UTF-8Transfer-Encoding: chunkedDate: Thu,21 Jun201807:36:58GMT{"result":"edit timer success"}
其他這里就不累述了。
說了這么多，這么多請求方式都是http協(xié)議的標準，你完全可以隨心所欲，全部用post或者全部用get，但是你要是開發(fā)的是商業(yè)產品，那你就要為你自己的隨便買單咯。
好比刪除一樣東西，如果用get請求方式：http:/xxx/delete?id=1,那你很快就知道，這些標準也能讓其他人一眼就能知道具體所要做的意思。?
HTTP狀態(tài)碼
HTTP狀態(tài)碼分類
分類分類描述
1**信息，服務器收到請求，需要請求者繼續(xù)執(zhí)行操作
2**成功，操作被成功接收并處理
3**重定向，需要進一步的操作以完成請求
4**客戶端錯誤，請求包含語法錯誤或無法完成請求
5**服務器錯誤，服務器在處理請求的過程中發(fā)生了錯誤
HTTP狀態(tài)碼列表
狀態(tài)碼狀態(tài)碼英文名稱中文描述
100Continue繼續(xù)。客戶端應繼續(xù)其請求
101Switching Protocols切換協(xié)議。服務器根據(jù)客戶端的請求切換協(xié)議。只能切換到
更高級的協(xié)議，例如，切換到HTTP的新版本協(xié)議
200OK請求成功。一般用于GET與POST請求
201Created已創(chuàng)建。成功請求并創(chuàng)建了新的資源
202Accepted已接受。已經(jīng)接受請求，但未處理完成
203Non-Authoritative Information非授權信息。請求成功。但返回的meta信息不在原始的服務器
，而是一個副本
204No Content無內容。服務器成功處理，但未返回內容。在未更新網(wǎng)頁
的情況下，可確保瀏覽器繼續(xù)顯示當前文檔
205Reset Content重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重
置文檔視圖。可通過此返回碼清除瀏覽器的表單域
206Partial Content部分內容。服務器成功處理了部分GET請求
300Multiple Choices多種選擇。請求的資源可包括多個位置，相應可返回一個
資源特征與地址的列表用于用戶終端（例如：瀏覽器）選擇
301Moved Permanently永久移動。請求的資源已被永久的移動到新URI，返回信息
會包括新的URI，瀏覽器會自動定向到新URI。今后任何新的請求
都應使用新的URI代替
302Found臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼
使用原有URI
303See Other查看其它地址。與301類似。使用GET和POST請求查看
304Not Modified未修改。所請求的資源未修改，服務器返回此狀態(tài)碼時，不會
返回任何源?？蛻舳送ǔ彺嬖L問過的資源，通過提供一個頭
信息指出客戶端希望只返回在指定日期之后修改的資源
305Use Proxy使用代理。所請求的資源必須通過代理訪問
306Unused已經(jīng)被廢棄的HTTP狀態(tài)碼
307Temporary Redirect臨時重定向。與302類似。使用GET請求重定向
400Bad Request客戶端請求的語法錯誤，服務器無法理解
401Unauthorized請求要求用戶的身份認證
402Payment Required保留，將來使用
403Forbidden服務器理解請求客戶端的請求，但是拒絕執(zhí)行此請求
404Not Found服務器無法根據(jù)客戶端的請求找到資源（網(wǎng)頁）。通過此代
碼，網(wǎng)站設計人員可設置"您所請求的資源無法找到"的個性
頁面
405Method Not Allowed客戶端請求中的方法被禁止
406Not Acceptable服務器無法根據(jù)客戶端請求的內容特性完成請求
407Proxy Authentication Required請求要求代理的身份認證，與401類似，但請求者應當使用代
理進行授權
408Request Time-out服務器等待客戶端發(fā)送的請求時間過長，超時
409Conflict服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理
請求時發(fā)生了沖突
410Gone客戶端請求的資源已經(jīng)不存在。410不同于404，如果資源以前有
現(xiàn)在被永久刪除了可使用410代碼，網(wǎng)站設計人員可通過301代碼
指定資源的新位置
411Length Required服務器無法處理客戶端發(fā)送的不帶Content-Length的請求信息
412Precondition Failed客戶端請求信息的先決條件錯誤
413Request Entity Too Large由于請求的實體過大，服務器無法處理，因此拒絕請求。為防
止客戶端的連續(xù)請求，服務器可能會關閉連接。如果只
是服務器暫時無法處理，則會包含一個Retry-After的響應信息
414Request-URI Too Large請求的URI過長（URI通常為網(wǎng)址），服務器無法處理
415Unsupported Media Type服務器無法處理請求附帶的媒體格式
416Requested range not satisfiable客戶端請求的范圍無效
417Expectation Failed服務器無法滿足Expect的請求頭信息
500Internal Server Error服務器內部錯誤，無法完成請求
501Not Implemented服務器不支持請求的功能，無法完成請求
502Bad Gateway充當網(wǎng)關或代理的服務器，從遠端服務器接收到了一個無效的請求
503Service Unavailable由于超載或系統(tǒng)維護，服務器暫時的無法處理客戶端的請求
。延時的長度可包含在服務器的Retry-After頭信息中
504Gateway Time-out充當網(wǎng)關或代理的服務器，未及時從遠端服務器獲取請求
505HTTP Version not supported服務器不支持請求的HTTP協(xié)議的版本，無法完成處理
結束語：其實我們大部分情況下只用到了GET和POST。如果想設計一個符合RESTful規(guī)范的web應用程序，則這六種方法都會用到。不過即使暫時不想涉及REST，
了解這六種方法的本質仍然是很有作用的。大家將會發(fā)現(xiàn)，原來web也是很簡潔明了的。下面再次依次說明這六種方法。
1，GET：GET可以說是最常見的了，它本質就是發(fā)送一個請求來取得服務器上的某一資源。資源通過一組HTTP頭和呈現(xiàn)據(jù)（如HTML文本，或者圖片或者視頻等）返回給客戶端。
GET請求中，永遠不會包含呈現(xiàn)數(shù)據(jù)。
2，HEAD：HEAD和GET本質是一樣的，區(qū)別在于HEAD不含有呈現(xiàn)數(shù)據(jù)，而僅僅是HTTP頭信息。有的人可能覺得這個方法沒什么用，其實不是這樣的。
想象一個業(yè)務情景：欲判斷某個資源是否存在，我們通常使用GET，但這里用HEAD則意義更加明確。
3，PUT：這個方法比較少見。HTML表單也不支持這個。本質上來講， PUT和POST極為相似，都是向服務器發(fā)送數(shù)據(jù)，但它們之間有一個重要區(qū)別，
PUT通常指定了資源的存放位置，而POST則沒有，POST的數(shù)據(jù)存放位置由服務器自己決定。舉個例子：如一個用于提交博文的URL，/addNew。
如果用PUT，則提交的URL會是像這樣的”/addNew/abc123”，其中abc123就是這個博文的地址。而如果用POST，則這個地址會在提交后由服務器告知客戶端。
目前大部分博客都是這樣的。顯然，PUT和POST用途是不一樣的。具體用哪個還取決于當前的業(yè)務場景。
4，DELETE：刪除某一個資源?；旧线@個也很少見，不過還是有一些地方比如amazon的S3云服務里面就用的這個方法來刪除資源。
5，POST：向服務器提交數(shù)據(jù)。這個方法用途廣泛，幾乎目前所有的提交操作都是靠這個完成。
6，OPTIONS：這個方法很有趣，但極少使用。它用于獲取當前URL所支持的方法。若請求成功，則它會在HTTP頭中包含一個名為“Allow”的頭，值是所支持的方法，如“GET, POST”。
無論從事什么行業(yè)，只要做好兩件事就夠了，一個是你的專業(yè)、一個是你的人品，專業(yè)決定了你的存在，人品決定了你的人脈，剩下的就是堅持，用善良專業(yè)和真誠贏取更多的信任
