1?HTTP協(xié)議詳解

HTTP是HyperText Transfer Protocol（超文本傳輸協(xié)議）的縮寫。它的發(fā)展是萬維網(wǎng)協(xié)會（WorldWide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結(jié)果，（他們）最終發(fā)布了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。

HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。

HTTP協(xié)議通常承載于TCP協(xié)議之上，有時也承載于TLS或SSL協(xié)議層之上，這個時候，就成了我們常說的HTTPS。如下圖所示：

? ? ? ? ? ??

默認(rèn)HTTP的端口號為80，HTTPS的端口號為443。

HTTP協(xié)議永遠都是客戶端發(fā)起請求，服務(wù)器回送響應(yīng)。見下圖：
? ??

這樣就限制了使用HTTP協(xié)議，無法實現(xiàn)在客戶端沒有發(fā)起請求的時候，服務(wù)器將消息推送給客戶端。

HTTP協(xié)議是一個無狀態(tài)的協(xié)議，同一個客戶端的這次請求和上次請求是沒有對應(yīng)關(guān)系。

一次HTTP操作稱為一個事務(wù)，其工作過程可分為四步：

1）首先客戶機與服務(wù)器需要建立連接。只要單擊某個超級鏈接，HTTP的工作開始。

2）建立連接后，客戶機發(fā)送一個請求給服務(wù)器，請求方式的格式為：統(tǒng)一資源標(biāo)識符（URL）、協(xié)議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內(nèi)容。

3）服務(wù)器接到請求后，給予相應(yīng)的響應(yīng)信息，其格式為一個狀態(tài)行，包括信息的協(xié)議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務(wù)器信息、實體信息和可能的內(nèi)容。

4）客戶端接收服務(wù)器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后客戶機與服務(wù)器斷開連接。

如果在以上過程中的某一步出現(xiàn)錯誤，那么產(chǎn)生錯誤的信息將返回到客戶端，有顯示屏輸出。對于用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標(biāo)點擊，等待信息顯示就可以了。

2??HTTP協(xié)議詳解之請求篇

? http請求由三部分組成，分別是：請求行、消息報頭、請求正文

請求行以一個方法符號開頭，以空格分開，后面跟著請求的URI和協(xié)議的版本，格式如下：Method Request-URIHTTP-Version CRLF??
其中 Method表示請求方法；Request-URI是一個統(tǒng)一資源標(biāo)識符；HTTP-Version表示請求的HTTP協(xié)議版本；CRLF表示回車和換行（除了作為結(jié)尾的CRLF外，不允許出現(xiàn)單獨的CR或LF字符）。

請求方法（所有方法全為大寫）有多種，各個方法的解釋如下：
GET???? 請求獲取Request-URI所標(biāo)識的資源
POST??? 在Request-URI所標(biāo)識的資源后附加新的數(shù)據(jù)
HEAD??? 請求獲取由Request-URI所標(biāo)識的資源的響應(yīng)消息報頭
PUT???? 請求服務(wù)器存儲一個資源，并用Request-URI作為其標(biāo)識
DELETE? 請求服務(wù)器刪除Request-URI所標(biāo)識的資源
TRACE?? 請求服務(wù)器回送收到的請求信息，主要用于測試或診斷
CONNECT 保留將來使用
OPTIONS 請求查詢服務(wù)器的性能，或者查詢與資源相關(guān)的選項和需求
應(yīng)用舉例：
GET方法：在瀏覽器的地址欄中輸入網(wǎng)址的方式訪問網(wǎng)頁時，瀏覽器采用GET方法向服務(wù)器獲取資源，eg:GET /form.html HTTP/1.1 (CRLF)

POST方法要求被請求服務(wù)器接受附在請求后面的數(shù)據(jù)，常用于提交表單。

HEAD方法與GET方法幾乎是一樣的，對于HEAD請求的回應(yīng)部分來說，它的HTTP頭部中包含的信息與通過GET請求所得到的信息是相同的。利用這個方法，不必傳輸整個資源內(nèi)容，就可以得到Request-URI所標(biāo)識的資源的信息。該方法常用于測試超鏈接的有效性，是否可以訪問，以及最近是否更新。

3??HTTP協(xié)議詳解之響應(yīng)篇

在接收和解釋請求消息后，服務(wù)器返回一個HTTP響應(yīng)消息。

HTTP響應(yīng)也是由三個部分組成，分別是：狀態(tài)行、消息報頭、響應(yīng)正文
1、狀態(tài)行格式如下：

HTTP-VersionStatus-Code Reason-Phrase CRLF
其中，HTTP-Version表示服務(wù)器HTTP協(xié)議的版本；Status-Code表示服務(wù)器發(fā)回的響應(yīng)狀態(tài)代碼；Reason-Phrase表示狀態(tài)代碼的文本描述。
狀態(tài)代碼有三位數(shù)字組成，第一個數(shù)字定義了響應(yīng)的類別，且有五種可能取值：
1xx：指示信息--表示請求已接收，繼續(xù)處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)
5xx：服務(wù)器端錯誤--服務(wù)器未能實現(xiàn)合法的請求
2、常見狀態(tài)代碼、狀態(tài)描述、說明：

請求收到，繼續(xù)處理
100——客戶必須繼續(xù)發(fā)出請求
101——客戶要求服務(wù)器根據(jù)請求轉(zhuǎn)換HTTP協(xié)議版本
操作成功收到，分析、接受
200——交易成功
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不確定或不完整
204——請求收到，但返回信息為空
205——服務(wù)器完成了請求，用戶代理必須復(fù)位當(dāng)前已經(jīng)瀏覽過的文件
206——服務(wù)器已經(jīng)完成了部分用戶的GET請求
完成此請求必須進一步處理
300——請求的資源可在多處得到
301——刪除請求數(shù)據(jù)
302——在其他地址發(fā)現(xiàn)了請求數(shù)據(jù)
303——建議客戶訪問其他URL或訪問方式
304——客戶端已經(jīng)執(zhí)行了GET，但文件未變化
305——請求的資源必須從服務(wù)器指定的地址得到
306——前一版本HTTP中使用的代碼，現(xiàn)行版本中不再使用
307——申明請求的資源臨時性刪除
請求包含一個錯誤語法或不能完成
400——錯誤請求，如語法錯誤
401——未授權(quán)
HTTP 401.1 -?未授權(quán)：登錄失敗
　　 HTTP 401.2 -?未授權(quán)：服務(wù)器配置問題導(dǎo)致登錄失敗
　　 HTTP 401.3 - ACL?禁止訪問資源
　　 HTTP 401.4 -?未授權(quán)：授權(quán)被篩選器拒絕
HTTP 401.5 -?未授權(quán)：ISAPI?或?CGI?授權(quán)失敗
402——保留有效ChargeTo頭響應(yīng)
403——禁止訪問
HTTP 403.1?禁止訪問：禁止可執(zhí)行訪問
　　 HTTP 403.2 -?禁止訪問：禁止讀訪問
　　 HTTP 403.3 -?禁止訪問：禁止寫訪問
　　 HTTP 403.4 -?禁止訪問：要求?SSL
　　 HTTP 403.5 -?禁止訪問：要求?SSL128
　　 HTTP 403.6 -?禁止訪問：IP?地址被拒絕
　　 HTTP 403.7 -?禁止訪問：要求客戶證書
　　 HTTP 403.8 -?禁止訪問：禁止站點訪問
　　 HTTP 403.9 -?禁止訪問：連接的用戶過多
　　 HTTP 403.10 -?禁止訪問：配置無效
　　 HTTP 403.11 -?禁止訪問：密碼更改
　　 HTTP 403.12 -?禁止訪問：映射器拒絕訪問
　　 HTTP 403.13 -?禁止訪問：客戶證書已被吊銷
　　 HTTP 403.15 -?禁止訪問：客戶訪問許可過多
　　 HTTP 403.16 -?禁止訪問：客戶證書不可信或者無效
HTTP 403.17 -?禁止訪問：客戶證書已經(jīng)到期或者尚未生效
404——沒有發(fā)現(xiàn)文件、查詢或URl
405——用戶在Request-Line字段定義的方法不允許
406——根據(jù)用戶發(fā)送的Accept拖，請求資源不可訪問
407——類似401，用戶必須首先在代理服務(wù)器上得到授權(quán)
408——客戶端沒有在用戶指定的餓時間內(nèi)完成請求
409——對當(dāng)前資源狀態(tài)，請求不能完成
410——服務(wù)器上不再有此資源且無進一步的參考地址
411——服務(wù)器拒絕用戶定義的Content-Length屬性請求
412——一個或多個請求頭字段在當(dāng)前請求中錯誤
413——請求的資源大于服務(wù)器允許的大小
414——請求的資源URL長于服務(wù)器允許的長度
415——請求資源不支持請求項目格式
416——請求中包含Range請求頭字段，在當(dāng)前請求資源范圍內(nèi)沒有range指示值，請求也不包含If-Range請求頭字段
417——服務(wù)器不滿足請求Expect頭字段指定的期望值，如果是代理服務(wù)器，可能是下一級服務(wù)器不能滿足請求長。
服務(wù)器執(zhí)行一個完全有效請求失敗
　　 HTTP 500 -?內(nèi)部服務(wù)器錯誤
　　 HTTP 500.100 -?內(nèi)部服務(wù)器錯誤?-ASP?錯誤
　　 HTTP 500-11?服務(wù)器關(guān)閉
　　 HTTP 500-12?應(yīng)用程序重新啟動
　　 HTTP 500-13 -?服務(wù)器太忙
　　 HTTP 500-14 -?應(yīng)用程序無效
　　 HTTP 500-15 -?不允許請求?global.asa
　　 Error 501 -?未實現(xiàn)
? ? ? ? HTTP 502 -?網(wǎng)關(guān)錯誤
　　 HTTP 500.100 -?內(nèi)部服務(wù)器錯誤?-ASP?錯誤
　　 HTTP 500-11?服務(wù)器關(guān)閉
　　 HTTP 500-12?應(yīng)用程序重新啟動
　　 HTTP 500-13 -?服務(wù)器太忙
　　 HTTP 500-14 -?應(yīng)用程序無效
　　 HTTP 500-15 -?不允許請求?global.asa
　　 Error 501 -?未實現(xiàn)
? ? ? ? HTTP 502 -?網(wǎng)關(guān)錯誤

4 API設(shè)計的基本要求

??一個被普遍承認(rèn)和遵守：RESTful設(shè)計原則。它被Roy Felding提出（在他的”基于網(wǎng)絡(luò)的軟件架構(gòu)“論文中第五章）。而REST的核心原則是將你的API拆分為邏輯上的資源。這些資源通過http被操作（GET ,POST,PUT,DELETE）。
? ??顯然從API用戶的角度來看，”資源“應(yīng)該是個名詞。即使你的內(nèi)部數(shù)據(jù)模型和資源已經(jīng)有了很好的對應(yīng)，API設(shè)計的時候你仍然不需要把它們一對一的都暴露出來。這里的關(guān)鍵是隱藏內(nèi)部資源，暴露必需的外部資源。
? ??一旦定義好了要暴露的資源，你可以定義資源上允許的操作，以及這些操作和你的API的對應(yīng)關(guān)系：

·???????GET /tickets #?獲取ticket列表

·???????GET /tickets/12 #?查看某個具體的ticket

·???????POST /tickets #?新建一個ticket

·???????PUT /tickets/12 #?更新ticket 12.

·???????DELETE /tickets/12 #刪除ticekt 12

? ??可以看出使用REST的好處在于可以充分利用http的強大實現(xiàn)對資源的CURD功能。而這里你只需要一個endpoint：/tickets,再沒有其他什么命名規(guī)則和url規(guī)則了，cool！
? ??但是有的endpoint，需要使用復(fù)數(shù)使得你的URL更加規(guī)整。這讓API使用者更加容易理解，對開發(fā)者來說也更容易實現(xiàn)。
如何處理關(guān)聯(lián)？關(guān)于如何處理資源之間的管理REST原則也有相關(guān)的描述：

·???????GET /tickets/12/messages- Retrieves list of messages forticket #12

·???????GET /tickets/12/messages/5- Retrieves message #5 forticket #12

·???????POST /tickets/12/messages- Creates a new message inticket #12

·???????PUT /tickets/12/messages/5- Updates message #5 for ticket#12

·???????PATCH /tickets/12/messages/5- Partially updates message#5 for ticket #12

·???????DELETE /tickets/12/messages/5- Deletes message #5 forticket #12

? ??其中，如果這種關(guān)聯(lián)和資源獨立，那么我們可以在資源的輸出表示中保存相應(yīng)資源的endpoint。然后API的使用者就可以通過點擊鏈接找到相關(guān)的資源。如果關(guān)聯(lián)和資源聯(lián)系緊密。資源的輸出表示就應(yīng)該直接保存相應(yīng)資源信息。（例如這里如果message資源是獨立存在的，那么上面 GET/tickets/12/messages就會返回相應(yīng)message的鏈接；相反的如果message不獨立存在，他和ticket依附存在，則上面的API調(diào)用返回直接返回message信息）

5 get和post區(qū)別

??? 常用的請求方式是GET和POST.

GET方式：是以實體的方式得到由請求URI所指定資源的信息，如果請求URI只是一個數(shù)據(jù)產(chǎn)生過程，那么最終要在響應(yīng)實體中返回的是處理過程的結(jié)果所指向的資源，而不是處理過程的描述。

POST方式：用來向目的服務(wù)器發(fā)出請求，要求它接受被附在請求后的實體，并把它當(dāng)作請求隊列中請求URI所指定資源的附加新子項，Post被設(shè)計成用統(tǒng)一的方法實現(xiàn)下列功能：

1）對現(xiàn)有資源的解釋；

2）向電子公告欄、新聞組、郵件列表或類似討論組發(fā)信息；

3）提交數(shù)據(jù)塊；

4）通過附加操作來擴展數(shù)據(jù)庫?。

從上面描述可以看出，Get是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請求；而Post是向服務(wù)器提交數(shù)據(jù)的一種請求，要提交的數(shù)據(jù)位于信息頭后面的實體中。

GET與POST方法有以下區(qū)別：

1）???在客戶端，Get方式在通過URL提交數(shù)據(jù)，數(shù)據(jù)在URL中可以看到；POST方式，數(shù)據(jù)放置在HTMLHEADER內(nèi)提交。

2）??GET方式提交的數(shù)據(jù)最多只能有1024字節(jié)，而POST則沒有此限制。

3）???安全性問題。正如在（1）中提到，使用?Get?的時候，參數(shù)會顯示在地址欄上，而?Post?不會。所以，如果這些數(shù)據(jù)是中文數(shù)據(jù)而且是非敏感數(shù)據(jù)，那么使用?get；如果用戶輸入的數(shù)據(jù)不是中文字符而且包含敏感數(shù)據(jù)，那么還是使用?post為好。

4）???安全的和冪等的。所謂安全的意味著該操作用于獲取信息而非修改信息。冪等的意味著對同一?URL?的多個請求應(yīng)該返回同樣的結(jié)果。完整的定義并不像看起來那樣嚴(yán)格。換句話說，GET?請求一般不應(yīng)產(chǎn)生副作用。從根本上講，其目標(biāo)是當(dāng)用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞?wù)军c的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認(rèn)為是安全的和冪等的，因為它總是返回當(dāng)前的新聞。反之亦然。POST?請求就不那么輕松了。POST?表示可能改變服務(wù)器上的資源的請求。仍然以新聞?wù)军c為例，讀者對文章的注解應(yīng)該通過?POST?請求實現(xiàn)，因為在注解提交之后站點已經(jīng)不同了（比方說文章下面出現(xiàn)一條注解）。

6 put和post區(qū)別

? ?有的觀點認(rèn)為，應(yīng)該用POST來創(chuàng)建一個資源，用PUT來更新一個資源；有的觀點認(rèn)為，應(yīng)該用PUT來創(chuàng)建一個資源，用POST來更新一個資源；還有的觀點認(rèn)為可以用PUT和POST中任何一個來做創(chuàng)建或者更新一個資源。這些觀點都只看到了風(fēng)格，爭論起來也只是爭論哪種風(fēng)格更好，其實，用PUT還是POST，不是看這是創(chuàng)建還是更新資源的動作，這不是風(fēng)格的問題，而是語義的問題。
? 舉一個簡單的例子，假如有一個博客系統(tǒng)提供一個Web API，模式是這樣http://superblogging/blogs/{blog-name}，很簡單，將{blog-name}
替換為我們的blog名字，往這個URI發(fā)送一個HTTP PUT或者POST請求，HTTP的body部分就是博文，這是一個很簡單的REST API例子。我們應(yīng)該用
PUT方法還是POST方法？取決于這個REST服務(wù)的行為是否是idempotent的，假如我們發(fā)送兩個http://superblogging/blogs/post/Sample請求，服
務(wù)器端是什么樣的行為？如果產(chǎn)生了兩個博客帖子，那就說明這個服務(wù)不是idempotent的，因為多次使用產(chǎn)生了副作用了嘛；如果后一個請求把第一個
請求覆蓋掉了，那這個服務(wù)就是idempotent的。前一種情況，應(yīng)該使用POST方法，后一種情況，應(yīng)該使用PUT方法。

總結(jié)

以上是生活随笔為你收集整理的关于restful协议很多人的误解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。