1?HTTP協議詳解

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

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

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

? ? ? ? ? ??

默認HTTP的端口號為80，HTTPS的端口號為443。

HTTP協議永遠都是客戶端發起請求，服務器回送響應。見下圖：
? ??

這樣就限制了使用HTTP協議，無法實現在客戶端沒有發起請求的時候，服務器將消息推送給客戶端。

HTTP協議是一個無狀態的協議，同一個客戶端的這次請求和上次請求是沒有對應關系。

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

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

2）建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。

3）服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。

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

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

2??HTTP協議詳解之請求篇

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

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

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

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

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

3??HTTP協議詳解之響應篇

在接收和解釋請求消息后，服務器返回一個HTTP響應消息。

HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文
1、狀態行格式如下：

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

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

4 API設計的基本要求

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

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

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

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

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

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

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

·???????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

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

5 get和post區別

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

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

POST方式：用來向目的服務器發出請求，要求它接受被附在請求后的實體，并把它當作請求隊列中請求URI所指定資源的附加新子項，Post被設計成用統一的方法實現下列功能：

1）對現有資源的解釋；

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

3）提交數據塊；

4）通過附加操作來擴展數據庫?。

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

GET與POST方法有以下區別：

1）???在客戶端，Get方式在通過URL提交數據，數據在URL中可以看到；POST方式，數據放置在HTMLHEADER內提交。

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

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

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

6 put和post區別

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。