玩轉 Postman：基礎篇

前言

本次 Chat 將結合業界廣爲推崇和使用的 RestAPI 設計典範 Github API，詳細介紹 Postman 接口測試工具的使用方法和實戰技巧。

在開始這個教程以前，先聊一下爲何接口測試在現軟件行業如此重要？ 爲何咱們要學習 Postman？

現代軟件行業已經從傳統的萬維網發展到移動互聯網，雲計算，現在更進入到萬物互聯時代。軟件和網絡會鏈接咱們生活的方方面面，不一樣的設備，不一樣的軟件系統之間存在各式各樣的聯繫。而接口就是不一樣設備、系統之間聯繫的橋樑，因此接口在現今和將來的軟硬件產業當中都具備愈來愈高的重要性和地位。

什麼是接口？

IT 行業從 WWW 萬維網時代 的 C/S、B/S 架構，到移動互聯網時代的大前端時代，發展到雲計算時代以 IaaS（基礎架構即服務），PaaS（平臺即服務），SaaS（軟件即服務）爲表明的雲端架構，現在更是進入到萬物互聯的物聯網時代，網絡鏈接着咱們生活的方方面面，而承載這些鏈接的鏈接點，就是網絡接口，接口是不一樣網絡應用之間聯繫、交互、相互做用的入口和橋樑。

以下圖，是接口在軟件系統中所處位置的示意圖： 這裏 UI 接口和 API 接口分別表明用戶交互接口和應用程序接口。

接口測試

瞭解了接口的概念，咱們再看什麼是接口測試？

如下是百度百科中給出的定義:

接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

能夠看到，在針對接口定義闡述後，也說明了接口測試的重點包括交互的數據、過程以及背後的業務邏輯。

再進一步看更經常使用的API測試的定義，這個百度沒有收錄，能夠看下 Wiki 百科的定義：

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security.[1] Since APIs lack a GUI, API testing is performed at the message layer.[2] API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps.[3][4]

它是直接針對 API 進行測試的一類集成測試，注意 wiki 把接口測試歸類在集成測試階段。也就是說它更可能是在系統集成時實施。而後也說明了接口測試不單純是功能測試，還需考慮可靠性、安全、性能等。API 接口測試和 GUI 測試不一樣，更多體如今消息層，而且由於 GUI 層在自動化測試上的先天劣勢，API 自動化目前是自動化測試領域以及敏捷、DevOps 等研發模式的關鍵實踐。

下圖是著名的測試金字塔，它根據不一樣測試類型對軟件測試進行了分層，底層是針對的代碼層面的單元測試，中間是 service 服務測試，而現今的應用服務更可能是 API 形式來體現，服務測試也能夠理解爲 API 的測試，上層則是針對用戶界面的 GUI 測試。

這個模型體現出在自動化測試中，越底層的自動化測試所佔比重應該越大，纔有更好的投入產出比。中間這一層的 API 測試它既不像 UI 層那樣維護成本巨大，很難跟上快速迭代的要求，同時它又比單元測試更能在業務邏輯上進行質量驗證。因此如今通常認爲API測試是自動化測試實施上的優先選擇

HTTP 協議基礎

在正式開始 Postman 的功能介紹前，首先仍是要介紹 Postman 的測試對象。Postman 主要是針對 HTTP 協議接口的測試工具，因此本章首先介紹一下 HTTP 協議的基礎知識。

HTTP，即超文本傳輸協議（HyperText Transfer Protocol)，是互聯網上應用最爲普遍的一種網絡協議，目前主要使用的 1.1 版本，基於 TCP/IP 通訊協議來傳遞數據（HTML、文件、數據、API 接口消息等）。

HTTP 協議工做於客戶端-服務器即 C/S 架構上 

HTTP 消息組成

客戶端發送一個 HTTP 請求到服務器，請求消息包括如下格式：

請求行（request line）、請求頭部（header）、空行和請求數據四個部分。如圖

以下是一個請求百度首頁的請求示例：

服務器接收並處理客戶端發過來的請求，返回一個 HTTP 的響應消息。也由四個部分組成，分別是：

響應狀態行、消息報頭、空行和響應正文。 如圖

以下是百度首頁的響應示例

HTTP 方法

HTTP 方法是請求消息中攜帶的關鍵信息，告知服務器本次請求但願進行的操做類型。目前在 HTTP1.1 版本中常見如下方法：

No.	方法	描述
1	GET	請求指定的頁面信息，並返回實體主體。
2	HEAD	相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
3	POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。
4	PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容。
5	DELETE	請求服務器刪除指定的頁面。
6	CONNECT	HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。
7	TRACE	回顯服務器收到的請求，主要用於測試或診斷。
8	PATCH	從客戶端向服務器傳送數據，取代指定文檔的部份內容

HTTP 狀態碼

HTTP 狀態碼定義了服務器端處理 HTTP 請求的結果信息，主要包含如下五類：

狀態碼	描述
1XX	已接收，待處理
2XX	請求處理成功
3XX	重定向，資源位置發生變化
4XX	客戶端請求信息錯誤
5XX	服務端處理髮生錯誤

1xx 消息

這一類型的狀態碼，表明請求已被接受，須要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。因爲 HTTP/1.0 協議中沒有定義任何 1xx 狀態碼，因此除非在某些試驗條件下，服務器禁止向此類客戶端發送 1xx 響應。這些狀態碼錶明的響應都是信息性的，標示客戶應該採起的其餘行動。

2xx 成功

這一類型的狀態碼，表明請求已成功被服務器接收、理解、並接受。

3xx 重定向

這類狀態碼錶明須要客戶端採起進一步的操做才能完成請求。一般，這些狀態碼用來重定向，後續的請求地址（重定向目標）在本次響應的 Location 域中指明。

4xx 客戶端錯誤

這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。除非響應的是一個 HEAD 請求，不然服務器就應該返回一個解釋當前錯誤情況的實體，以及這是臨時的仍是永久性的情況。這些狀態碼適用於任何請求方法。瀏覽器應當向用戶顯示任何包含在此類錯誤響應中的實體內容

5xx 服務器錯誤

表示服務器沒法完成明顯有效的請求。這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生，也有多是服務器意識到以當前的軟硬件資源沒法完成對請求的處理。除非這是一個 HEAD 請求，不然服務器應當包含一個解釋當前錯誤狀態以及這個情況是臨時的仍是永久的解釋信息實體。瀏覽器應當向用戶展現任何在當前響應中被包含的實體。這些狀態碼適用於任何響應方法。

詳細的狀態碼清單可參見附錄

GitHub API

後面會有針對 github API 的實例，此處簡要介紹下 Github 網站以及 Github API。

GitHub 是一個面向開源及私有軟件項目的託管平臺，由於只支持 Git 做爲惟一的版本庫格式進行託管，故名 GitHub。也是目前全球最大的代碼託管平臺，能夠說是程序員的聖地，號稱全球最大的同性交友平臺。

github 中的一些主要概念

1. 提交（commit）：提交更改到倉庫（注意本地 Gi t倉庫與 GitHub 倉庫不一樣）。
2. 提交信息（commit message）：每次提交的時候，描述此次提交內容的信息。
3. 分支（branch）：像樹狀圖同樣，每一個獨立的分支均可看做是項目的一個版本
4. 主分支（master branch）：全部的 Git 項目在最初建立時，都會默認建立出一個主分支。在開發中，寫一個新功能的時候，通常都是先創建一個分支，在該分支上完成功能，發佈時 merge 到主分支。
5. 功能分支（feature branch）：通常的功能開發分支
6. 發佈分支（release branch）：每次正式發佈時，能夠拉出一個 release 分支來凍結當前 release 的代碼。
7. 合併（merge）：merge 能夠將一個分支上的所有內容歸併到另外一個分支上
8. 標籤（tag）：經常使用於記錄發佈版本，在版本發佈的時候，給一個 tag，便於管理和查詢
9. 導出（check out）：從某一分支上查看內容記錄。
10. 拉取（pull request）：通常用來從遠程倉庫拉取分支中的代碼到本地，也能夠從本地倉庫中拉取分支代碼到當前工程中。
11. 提出問題（issue）：GitHub 的提出問題的功能，通常遇到問題，能夠將出現問題的場合，經過 issue 的方式記錄。
12. 維基（WIKI）：一個輕量級的知識庫，建立的 Web 頁面之間能夠經過連接互相聯繫。GitHub 中的項目一般使用 WIKi 進行文檔記錄。
13. 克隆（clone）：從 GitHub 上下載一個副本到本地，操做後能夠 pull 上去。
14. 分叉（fork）：A 複製一個 B 的項目到本身的帳戶下，修改後再提交，B 能看到 A 修改的內容，可是 B 本來的項目是不會有變更的。

github 主界面功能

圖片來自網絡

Github API

目前 Github API 最新的 V4 版本是基於 GraphQL 的 API，但最經常使用的仍是 V3 的 Restful API。

Github API 中幾類主要資源及對應操做

User 資源

Repo 操做

issue 操做

圖片來自網絡

Github 中的時間格式

Github 中時間格式以下：

YYYY-MM-DDTHH:MM:SSZ

Github 限流規則

Github 爲包含服務端負載壓力，會對請求流量進行限制。在每一個 Github 的響應消息頭中都會攜帶 Github 的限流設置。

頭參數	含義
X-RateLimit-Limit	當前每小時最大請求限制，通常未鑑權請求60次，鑑權請求5000次
X-RateLimit-Remaining	當前剩餘請求次數
X-RateLimit-Reset	剩餘限制重置時間，毫秒

請求參數與分頁

請求中能夠攜帶參數，通常包含兩種參數: 路徑參數和查詢參數。 

Github API中還默認支持兩個分頁參數：

• page 當前顯示頁數；
• per_page 每頁顯示結果數。

Postman 基礎

能夠用於 Rest 接口測試的測試工具很是多，常見的有 soapUI、Jmeter、fiddler 等都常常用來作接口測試。可是目前在接口測試人員中最流行，最多見仍是本文向你們介紹的 Postman。

Postman 的安裝

Postman 最先的版本，以及很長一段時間都是以 Chrome 插件的形式存在的。以致不少人甚至認爲 Postman 就是 Google 的官方工具插件，咱們目前能看到的不少資料也仍是基於 Chrome 的插件形式來進行介紹的。

可是目前 Postman 其實已經推出了獨立的本地App程序，而且官方已經宣佈再也不支持 Chrome 的插件形式。雖然插件版本如今還能使用，但是畢竟相比 Native 版本，受限於 Chrome 瀏覽器的功能，不少功能在插件版本中是欠缺的，好比 cookie 的內建支持，代理功能，控制檯功能等等。因此此處就再也不介紹插件版本的安裝。

本地版本的安裝，其實也很是簡單。從官網根據本身操做系統的類型選擇相應的版本下載便可。 

這裏還有一點要注意下，在 Postman 的官網，咱們最好註冊一個帳號，後續在使用 Postman 的時候不少高級功能須要用這個帳號登陸後纔可使用。

安裝完成，在桌面上出現 Postman 那個 pose 很帥的小人圖標，則安裝完成。

Postman 主界面

打開 Postman 進入，首次會提示選擇但願建立的任務類型。

這裏有六種任務類型，這裏先簡單說明一下：

• Request是 Postman 軟件的基礎和核心，也就是經過這個功能來建立 request 請求，完成接口測試的核心工做；
• Collection實際上是個集合，咱們能夠認爲是一批 Request 請求的集合，或者說測試集。它也是 Postman 一些進階功能的基本單位；
• Environment 字面理解就是環境，其實能夠認爲是一些配置變量的集合，實際應用中能夠起到經過不一樣配置區分不一樣測試環境的效果 後面這三個都是 Postman 的高級功能；
• API documention 是經過咱們調試經過的 request 來自動生成接口文檔，便於團隊的共享和接口的交付；
• Mock server 在咱們進行接口測試或開發的時候，不少時候是須要模擬對端的接口服務器的，Mock server 就起到的模擬服務器端的做用；
• Monitor 這是個監控功能，經過 monitor 我能夠監控個人接口是否是正常。說白了，這其實就是個定時的接口執行功能。

以上大體瞭解了幾種不一樣的任務類型，下面咱們再來看看主界面的功能區。 

Banner 區域

首先是上面的菜單欄，對應功能區的各項功能，在菜單欄上都能找到對應的菜單。而後是下面的 banner 區域。

從左到右依次介紹：

會打開啓動時的建立窗口，用於建立六種類型的任務。

按鈕，能夠用於導入外部文件，外部文件能夠是 postman 的 Collection 格式文件，數據文件，以及其餘的 API 定義文件。

則會啓動 Collection runner，它是一個運行器，用於運行已經創建的測試任務，咱們後面會有詳細介紹。

第四個按鈕，能夠新建 tab，或者多開一個 postman 程序，或者 runer 程序。

中間是選擇使用的 workspace，但這個須要帳號登陸，會同步雲端的 workspace 設置。每一個帳號會有一個默認的 workspace，workspace 它是一個工做空間，你們能夠理解成相似項目或者工程。

banner 條右側還有幾個按鈕： 

• 第一個是同步，也是在有帳號的狀況下，能夠在多個電腦間同步 workspace 內的相關接口測試設計；
• 第二個 proxy，則相似前面介紹過的 fiddler，提供代理抓取 API 功能。固然這個功能 postman 不像 Fiddler 那樣豐富；
• 第三個按鈕包括 setting 以及文檔指南。 setting 裏是軟件的本地配置
• 第四個按鈕是消息通知，很好理解，會顯示一些提醒信息；
• 而後是 postman 的 Twitter，在牆後面就不要去看了；
• 最後是登陸，能夠用 postman 的帳號的登陸。

Setting 設置

Postman 工具的使用屬性和應用設置咱們能夠在 Setting 中國進行設置。如下分別說明：

General

Themes

Shortcuts

工具快捷鍵 

Data

工具數據導入導出 

add-ons

Newman 插件下載方法 

Sync

同步設置 

certificates

本地證書設置 

Proxy

本地網絡代理設置 

update

升級設置 

about

工具 關於... 等版本信息 

左側邊欄

• filter 篩選欄，篩選顯示不一樣的消息
• history 是操做消息記錄清單
• collection 如前面介紹，顯示請求集合

底邊狀態欄

• 最左面，顯示和關閉左側邊欄
• 而後是搜索功能，這個容易理解
• 第三個是控制檯，能夠在這裏看到消息相互的詳細信息

• 用戶指南
• 調整功能區顯示樣式
• 快捷鍵清單參考
• 幫助相關的鏈接

主功能區

主要包括上下兩部分，上面是 request 區，下面是 response 區。也能夠分紅左右顯示。

Request 區域

request 部分默認開啓了一個選項卡，能夠新開多個選項卡便於同時編輯。

默認使用的是 GET 方法，這也是使用最多的 HTTP 方法，下拉能夠選擇其餘的方法，經常使用的還有哪些？ POST、PUT、Delete 等。

URL 部分輸入請求的地址。好比咱們輸入 Github API 的根地址。

param 是參數管理界面，在這裏咱們能夠添加參數（有 key-value，塊編輯模式）。

Send 發送請求，小箭頭下 send and download，會在發送之後把響應消息導出成 json 保存。旁邊的 save，保存功能，實際上是把這個 request 做爲一個 case 保存到 collection 裏。

鑑權部分，雖然 request 編輯器已經足夠強大能夠處理鑑權消息，可是不少時候鑑權是個使用頻率很高的功能，因此 Postman 單獨把鑑權部分抽取出來，而且封裝了目前的絕大部分鑑權方式

• 繼承，默認鑑權方式

• 不鑑權

• bearer token 鑑權，通常也叫 Json web token，其實就是發送一個 json 格式的 token 令牌，服務端會針對 token 進行解密驗證

• Basic Auth 基礎驗證，提供用戶名密碼驗證，postman 會自動生成 authorization，經常使用鑑權方式

• digest auth，摘要式認證。在基自己份認證上面擴展了安全性，服務器爲每個鏈接生成一個惟一的隨機數，客戶端用這個隨機數對密碼進行 MD5 加密，而後返回服務器，服務器也用這個隨機數對密碼進行加密，而後和客戶端傳送過來的加密數據進行比較,若是一致就返回結果。

  它是一個二次驗證的過程，會有兩次認證交互消息。客戶端請求資源->服務器返回認證標示->客戶端發送認證信息->服務器查驗認證。

• Oauth，通常用於第三方認證，有1,2兩個版本，須要提供的信息不太同樣。也是經常使用的鑑權方式

• Hawk 認證，是另外一種認證方案，採用的叫消息碼認證算法，和 Digest 認證相似，它也是須要二次交互的

• AWS 簽名認證，是針對亞馬遜的 AWS 公有云用戶簽名的認證方式

• NTLM 是微軟的局域網管理認證協議

通常比較經常使用的就是 Basic 以及 OAuth2 了。

header 就是消息頭管理，能夠定義頭部信息。

Body，請求消息體。通常 Post、put、patch 等會更新內容的請求才會攜帶消息體，

旁邊 pre-script，是指在請求發送前，能夠作一些預處理的工做，相似 junit 等單元測試框架中的 setup 方法，支持 js 腳本語法

Test 則是在響應之後，對響應進行校驗或其餘處理的，相似 junit 框架中的 teardown 方法，一樣支持 js 腳本語法

cookie 管理 postman 本地 cookie 信息

code 是一個方便程序員的功能，能夠自動將接口請求轉化成相關語言編碼，能夠看到支持的語言很是豐富，基本涵蓋了各類主流編程語言。

Response 區域

響應消息右上角是狀態碼，懸停能夠看到詳細解釋。另外是響應時間（從發出請求到返回客戶端接收的時間），以及消息大小（含消息頭和消息體）。

響應 body 部分，即消息體。包括如下幾個按鈕

• pretty，能夠根據表現類型進行格式化顯示，默認 json，若是是其餘格式類型，能夠選擇對應形式進行格式化。
• Raw 是未格式化的形式
• preview 是預覽，就是在瀏覽器裏渲染後呈現的樣子，若是返回的是 html 格式就會很直觀。
• 再旁邊是自動換行按鈕。

右邊是拷貝到剪切板和查詢按鈕（支持正則，大小寫敏感、全詞匹配等設置）。

其餘的幾個 tab：

• cookie：響應消息的 cookie 信息
• header：響應消息的 header 頭部信息
• Test Results：在請求中添加 test Script 後，這裏會顯示測試腳本的校驗結果 

Postman 中完成 Github 鑑權

下面結合 Github API 看下如何在 Postman 中進行接口測試。從 Github API 文檔中，咱們能夠看到 Github API 支持多種鑑權方式。

• Basic authentication

這是基本鑑權方式

• OAuth2 token (sent in a header)

也支持經過在 Header 中攜帶 Oauth2 的 token 進行鑑權。在 Github 用戶設置中能夠生成這個 token。

我的設置 > Settings > Developer settings > Personal access tokens 生成後會得到一個 token 字串 

• OAuth2 token (sent as a parameter)

或者經過在 URL 中攜帶 token 參數鑑權。

Postman 中，能夠在 Collection 中設置鑑權 在具體的請求消息中，能夠選擇 Inherit auth from parent，即繼承上一層的鑑權。發送請求後，能夠看到已經在 header 中攜帶了鑑權的 token 信息。 

根據 Github API 的定義，對於請求有訪問限制，即未鑑權的請求限制訪問爲每分鐘 60 次，對於已鑑權的請求訪問每分鐘 5000 次。

咱們從響應消息的消息頭中能夠看到這個設置，如：

Postman 實現基本 HTTP 方法

再來看如何在 Postman 中實現經常使用的 HTTP 方法。仍是以 Github API 爲例：

GET 方法 - 獲取 Repo 信息

GET /repos/:owner/:repo

這裏是獲取 Github上 Repo 信息的 API，這裏有兩個路徑參數，owner 表明用戶帳號，repo 指須要獲取的 repo 信息。

如圖是在 Postman 中設置路徑參數的方法。 

POST 方法 - 建立 Repo

建立 Repo 的示例(https://developer.github.com/v3/repos/#create)

POST /user/repos

這裏是一個建立 hello world 的 Repo 的請求消息體示例

這裏 name 是必填字段，其餘是 repo 的屬性設置。 在 Postman 中如圖提交，返回狀態碼 201 created，便可建立一個 Hello world 的 Repo。 

在 Github 中，能夠看到帳號下新增了一個 hello world 的 repo，而且包含有已設置的 issue、projects、Wiki 這幾個欄目。 

PATCH 方法 - 修改 Repo

GitHub 能夠經過 PATCH 方法來對 Repo 進行修改。PATCH 方法和 PUT 方法都是 update 的修改方法，但 PATCH 方法更多用在部分修改的場景下，PUT 方法則更可能是總體替換。

PATCH /repos/:owner/:repo

好比上例中 hello world 這個 Repo 修改 Repo 中的部分信息，能夠去除 projects 和 Wiki 這兩個欄目。

消息體：

Postman 中如圖： 

回到 Github，能夠看到 Repo 中對應的欄目已經不見了。 

PUT 方法 - 設置或替換 Topic

Topic 是 Github 上 Repo 的搜索關鍵字，便於用戶進行 Repo 查詢。

PUT /repos/:owner/:repo/topics

Github API 設置 topic 的 API 是使用 put 方法提交一個 topic 數組，如

這時在 Postman 中提交，會發現有以下報錯： 

這是由於 Github API 要求設置 topic 時，須要在 header 中設置 accept 字段，取值：

application/vnd.github.mercy-preview+json

正確設置後，則能夠看到設置成功，返回 200。 

你們可能會發現一個小 bug，當設置的 topic 存在大寫字符時，會出現格式報錯。好比你們參照官方示例設置"API"這樣的 topic，會發現設置不成功。你們能夠嘗試一下。

DELETE 方法 - 刪除 Repo

Github API 中，使用 delete 方法能夠刪除 repo。

DELETE /repos/:owner/:repo

刪除成功後，返回 204。 此時再查詢帳號，應該發現 Hello-World 這個 repo 已經被刪除了

結語及預告

至此，咱們經過 Github API 中幾個實際的例子，學習瞭如何經過 Postman 來完成一些基本的 HTTP 方法的請求發送和響應查看，經過查看結果狀態碼或響應內容來判斷結果正確性。

固然 Postman 的功能遠不止於此，API接口測試中也還有不少複雜的場景須要特別處理。

歡迎你們繼續關注後續 Chat：《玩轉 Postman - 進階篇》。在進階篇中咱們將繼續深刻講解 Postman 的進階功能，並結合一些複雜的實例場景來學習：

• Postman 的環境和變量 
• Postman 變量類型及其做用域
• Postman 如何經過內建腳本實現接口預處理
• Postman 實現測試結果的腳本校驗
• Postman 腳本執行順序
• 如何實現接口的關聯測試
• Postman 中的 JavaScript 擴展

附錄

HTTP 狀態碼詳解（譯自 Wiki 百科，目前所見最全面的解釋）。

1xx 消息

這一類型的狀態碼，表明請求已被接受，須要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。因爲 HTTP/1.0 協議中沒有定義任何 1xx 狀態碼，因此除非在某些試驗條件下，服務器禁止向此類客戶端發送 1xx 響應。這些狀態碼錶明的響應都是信息性的，標示客戶應該採起的其餘行動。

100 Continue

服務器已經接收到請求頭，而且客戶端應繼續發送請求主體（在須要發送身體的請求的狀況下：例如，POST 請求），或者若是請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。要使服務器檢查請求的頭部，客戶端必須在其初始請求中發送 Expect: 100-continue 做爲頭部，並在發送正文以前接收 100 Continue 狀態代碼。響應代碼 417 指望失敗表示請求不該繼續。

101 Switching Protocols

服務器已經理解了客戶端的請求，並將經過 Upgrade 消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在 Upgrade 消息頭中定義的那些協議。

只有在切換新的協議更有好處的時候才應該採起相似措施。例如，切換到新的 HTTP 版本（如 HTTP/2）比舊版本更有優點，或者切換到一個實時且同步的協議（如 WebSocket）以傳送利用此類特性的資源。

102 Processing（WebDAV；RFC 2518）

WebDAV 請求可能包含許多涉及文件操做的子請求，須要很長時間才能完成請求。該代碼表示​​服務器已經收到並正在處理請求，但無響應可用。這樣能夠防止客戶端超時，並假設請求丟失。

2xx 成功

這一類型的狀態碼，表明請求已成功被服務器接收、理解、並接受。

200 OK

請求已成功，請求所但願的響應頭或數據體將隨此響應返回。實際的響應將取決於所使用的請求方法。在 GET 請求中，響應將包含與請求的資源相對應的實體。在 POST 請求中，響應將包含描述或操做結果的實體。

201 Created

請求已經被實現，並且有一個新的資源已經依據請求的須要而建立，且其 URI 已經隨 Location 頭信息返回。假如須要的資源沒法及時建立的話，應當返回 '202 Accepted'。

202 Accepted

服務器已接受請求，但還沒有處理。最終該請求可能會也可能不會被執行，而且可能在處理髮生時被禁止。

203 Non-Authoritative Information（自 HTTP / 1.1 起）

服務器是一個轉換代理服務器（transforming proxy，例如網絡加速器），以 200 OK 狀態碼爲起源，但迴應了原始響應的修改版本。

204 No Content

服務器成功處理了請求，沒有返回任何內容。

205 Reset Content

服務器成功處理了請求，但沒有返回任何內容。與 204 響應不一樣，此響應要求請求者重置文檔視圖。

206 Partial Content（RFC 7233）

服務器已經成功處理了部分GET請求。相似於FlashGet或者迅雷這類的HTTP 下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解爲多個下載段同時下載。

207 Multi-Status（WebDAV；RFC 4918）

表明以後的消息體將是一個 XML 消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼。

208 Already Reported （WebDAV；RFC 5842）

DAV 綁定的成員已經在（多狀態）響應以前的部分被列舉，且未被再次包含。

226 IM Used （RFC 3229）

服務器已經知足了對資源的請求，對實體請求的一個或多個實體操做的結果表示。

3xx 重定向

這類狀態碼錶明須要客戶端採起進一步的操做才能完成請求。一般，這些狀態碼用來重定向，後續的請求地址（重定向目標）在本次響應的 Location 域中指明。

當且僅當後續的請求所使用的方法是 GET 或者 HEAD 時，用戶瀏覽器才能夠在沒有用戶介入的狀況下自動提交所須要的後續請求。客戶端應當自動監測無限循環重定向（例如：A→B→C→……→A 或 A→A），由於這會致使服務器和客戶端大量沒必要要的資源消耗。按照 HTTP/1.0 版規範的建議，瀏覽器不該自動訪問超過 5 次的重定向。

300 Multiple Choices

被請求的資源有一系列可供選擇的回饋信息，每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇一個首選的地址進行重定向。

除非這是一個 HEAD 請求，不然該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動做出最合適的選擇。固然，RFC 2616 規範並無規定這樣的自動選擇該如何進行。

若是服務器自己已經有了首選的回饋選擇，那麼在 Location 中應當指明這個回饋的 URI；瀏覽器可能會將這個 Location 值做爲自動重定向的地址。此外，除非額外指定，不然這個響應也是可緩存的。

301 Moved Permanently

被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定，不然這個響應也是可緩存的。

新的永久性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，不然響應的實體中應當包含指向新的 URI 的超連接及簡短說明。 若是這不是一個 GET 或者 HEAD 請求，所以瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。

注意：對於某些使用 HTTP/1.0 協議的瀏覽器，當它們發送的 POST 請求獲得了一個 301 響應的話，接下來的重定向請求將會變成 GET 方式。

302 Found

要求客戶端執行臨時重定向（原始描述短語爲「Moved Temporarily」）。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在 Cache-Control 或 Expires 中進行了指定的狀況下，這個響應纔是可緩存的。

新的臨時性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，不然響應的實體中應當包含指向新的 URI 的超連接及簡短說明。 若是這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。

注意：雖然 RFC 1945 和 RFC 2068 規範不容許客戶端在重定向時改變請求的方法，可是不少現存的瀏覽器將 302 響應視做爲 303 響應，而且使用 GET 方式訪問在 Location 中規定的 URI，而無視原先請求的方法。所以狀態碼 303 和 307 被添加了進來，用以明確服務器期待客戶端進行何種反應。

303 See Other

對應當前請求的響應能夠在另外一個 URI 上被找到，當響應於 POST（或 PUT / DELETE）接收到響應時，客戶端應該假定服務器已經收到數據，而且應該使用單獨的 GET 消息發出重定向。這個方法的存在主要是爲了容許由腳本激活的 POST 請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用。同時，303 響應禁止被緩存。固然，第二個請求（重定向）可能被緩存。

新的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，不然響應的實體中應當包含指向新的 URI 的超連接及簡短說明。

注意：許多 HTTP/1.1 版之前的瀏覽器不能正確理解 303 狀態。若是須要考慮與這些瀏覽器之間的互動，302 狀態碼應該能夠勝任，由於大多數的瀏覽器處理 302 響應時的方式偏偏就是上述規範要求客戶端處理 303 響應時應當作的。

304 Not Modified

表示資源未被修改，由於請求頭指定的版本 If-Modified-Since 或 If-None-Match。在這種狀況下，因爲客戶端仍然具備之前下載的副本，所以不須要從新傳輸資源。

305 Use Proxy

被請求的資源必須經過指定的代理才能被訪問。Location 域中將給出指定的代理所在的 URI 信息，接收者須要重複發送一個單獨的請求，經過這個代理才能訪問相應資源。只有原始服務器才能建立 305 響應。許多 HTTP 客戶端（像是 Mozilla 和 Internet Explorer）都沒有正確處理這種狀態代碼的響應，主要是出於安全考慮。

注意：RFC 2068 中沒有明確 305 響應是爲了重定向一個單獨的請求，並且只能被原始服務器創建。忽視這些限制可能致使嚴重的安全後果。

306 Switch Proxy

在最新版的規範中，306 狀態碼已經再也不被使用。最初是指「後續請求應使用指定的代理」。

307 Temporary Redirect

在這種狀況下，請求應該與另外一個 URI 重複，但後續的請求應仍使用原始的 URI。 與 302 相反，當從新發出原始請求時，不容許更改請求方法。 例如，應該使用另外一個 POST 請求來重複 POST 請求。

308 Permanent Redirect (RFC 7538)

請求和全部未來的請求應該使用另外一個 URI 重複。 307 和 308 重複 302 和 301 的行爲，但不容許 HTTP 方法更改。 例如，將表單提交給永久重定向的資源可能會順利進行。

4xx 客戶端錯誤

這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。除非響應的是一個 HEAD 請求，不然服務器就應該返回一個解釋當前錯誤情況的實體，以及這是臨時的仍是永久性的情況。這些狀態碼適用於任何請求方法。瀏覽器應當向用戶顯示任何包含在此類錯誤響應中的實體內容。

若是錯誤發生時客戶端正在傳送數據，那麼使用 TCP 的服務器實現應當仔細確保在關閉客戶端與服務器之間的鏈接以前，客戶端已經收到了包含錯誤信息的數據包。若是客戶端在收到錯誤信息後繼續向服務器發送數據，服務器的 TCP 棧將向客戶端發送一個重置數據包，以清除該客戶端全部還未識別的輸入緩衝，以避免這些數據被服務器上的應用程序讀取並干擾後者。

400 Bad Request

因爲明顯的客戶端錯誤（例如，格式錯誤的請求語法，太大的大小，無效的請求消息或欺騙性路由請求），服務器不能或不會處理該請求。

401 Unauthorized（RFC 7235）

參見：HTTP 基本認證、HTTP 摘要認證。

相似於 403 Forbidden，401 語義即「未認證」，即用戶沒有必要的憑據。該狀態碼錶示當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的 Authorization 頭信息的請求。若是當前請求已經包含了 Authorization 證書，那麼 401 響應表明着服務器驗證已經拒絕了那些證書。若是 401 響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。

注意：當網站（一般是網站域名）禁止 IP 地址時，有些網站狀態碼顯示的 401，表示該特定地址被拒絕訪問網站。

402 Payment Required

該狀態碼是爲了未來可能的需求而預留的。該狀態碼最初的意圖可能被用做某種形式的數字現金或在線支付方案的一部分，但幾乎沒有哪家服務商使用，並且這個狀態碼一般不被使用。若是特定開發人員已超過請求的每日限制，Google Developers API 會使用此狀態碼。

403 Forbidden

主條目：HTTP 403

服務器已經理解請求，可是拒絕執行它。與 401 響應不一樣的是，身份驗證並不能提供任何幫助，並且這個請求也不該該被重複提交。若是這不是一個 HEAD 請求，並且服務器但願可以講清楚爲什麼請求不能被執行，那麼就應該在實體內描述拒絕的緣由。固然服務器也能夠返回一個 404 響應，假如它不但願讓客戶端得到任何信息。

404 Not Found

主條目：HTTP 404

請求失敗，請求所但願獲得的資源未被在服務器上發現，但容許用戶的後續請求。沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的。假如服務器知道狀況的話，應當使用 410 狀態碼來告知舊資源由於某些內部的配置機制問題，已經永久的不可用，並且沒有任何能夠跳轉的地址。404 這個狀態碼被普遍應用於當服務器不想揭示到底爲什麼請求被拒絕或者沒有其餘適合的響應可用的狀況下。

405 Method Not Allowed

請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個 Allow 頭信息用以表示出當前資源可以接受的請求方法的列表。例如，須要經過 POST 呈現數據的表單上的GET請求，或只讀資源上的 PUT 請求。

鑑於 PUT，DELETE 方法會對服務器上的資源進行寫操做，於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，對於此類請求均會返回 405 錯誤。

406 Not Acceptable

參見：內容協商

請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體，該請求不可接受。

除非這是一個 HEAD 請求，不然該響應就應當返回一個包含可讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由 Content-Type 頭中定義的媒體類型決定。瀏覽器能夠根據格式及自身能力自行做出最佳選擇。可是，規範中並無定義任何做出此類自動選擇的標準。

407 Proxy Authentication Required（RFC 2617）

與 401 響應相似，只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問。客戶端能夠返回一個 Proxy-Authorization 信息頭用以驗證。

408 Request Timeout

請求超時。根據 HTTP 規範，客戶端沒有在服務器預備等待的時間內完成一個請求的發送，客戶端能夠隨時再次提交這一請求而無需進行任何更改。

409 Conflict

表示由於請求存在衝突沒法處理該請求，例如多個同步更新之間的編輯衝突。

410 Gone

表示所請求的資源再也不可用，將再也不可用。當資源被有意地刪除而且資源應被清除時，應該使用這個。在收到 410 狀態碼後，用戶應中止再次請求資源。但大多數服務端不會使用此狀態碼，而是直接使用 404 狀態碼。

411 Length Required

服務器拒絕在沒有定義 Content-Length 頭的狀況下接受請求。在添加了代表請求消息體長度的有效 Content-Length 頭以後，客戶端能夠再次提交該請求。

412 Precondition Failed（RFC 7232）

服務器在驗證在請求的頭字段中給出先決條件時，沒能知足其中的一個或多個。這個狀態碼容許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其但願的內容之外的資源上。

413 Request Entity Too Large（RFC 7231）

前稱「Request Entity Too Large」，表示服務器拒絕處理當前請求，由於該請求提交的實體數據大小超過了服務器願意或者可以處理的範圍。此種狀況下，服務器能夠關閉鏈接以避免客戶端繼續發送此請求。

若是這個情況是臨時的，服務器應當返回一個 Retry-After 的響應頭，以告知客戶端能夠在多少時間之後從新嘗試。

414 Request-URI Too Long（RFC 7231）

前稱「Request-URI Too Long」，表示請求的 URI 長度超過了服務器可以解釋的長度，所以服務器拒絕對該請求提供服務。一般將太多數據的結果編碼爲GET請求的查詢字符串，在這種狀況下，應將其轉換爲 POST 請求。這比較少見，一般的狀況包括：

本應使用 POST 方法的表單提交變成了 GET 方法，致使查詢字符串過長。

重定向 URI「黑洞」，例如每次重定向把舊的 URI 做爲新的 URI 的一部分，致使在若干次重定向後 URI 超長。

客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器。這類服務器使用固定長度的緩衝讀取或操做請求的 URI，當 GET 後的參數超過某個數值後，可能會產生緩衝區溢出，致使任意代碼被執行。沒有此類漏洞的服務器，應當返回 414 狀態碼。

415 Unsupported Media Type

對於當前請求的方法和所請求的資源，請求中提交的互聯網媒體類型並非服務器中所支持的格式，所以請求被拒絕。例如，客戶端將圖像上傳格式爲 svg，但服務器要求圖像使用上傳格式爲 jpg。

416 Requested Range Not Satisfiable（RFC 7233）

前稱「Requested Range Not Satisfiable」。客戶端已經要求文件的一部分（Byte serving），但服務器不能提供該部分。例如，若是客戶端要求文件的一部分超出文件尾端。

417 Expectation Failed

在請求頭 Expect 中指定的預期內容沒法被服務器知足，或者這個服務器是一個代理服顯的證據證實在當前路由的下一個節點上，Expect 的內容沒法被知足。

418 I'm a teapot（RFC 2324）

本操做碼是在 1998 年做爲 IETF 的傳統愚人節笑話, 在 RFC 2324 超文本咖啡壺控制協議中定義的，並不須要在真實的 HTTP 服務器中定義。當一個控制茶壺的 HTCPCP 收到 BREW 或 POST 指令要求其煮咖啡時應當回傳此錯誤。這個 HTTP 狀態碼在某些網站（包括 Google.com）與項目（如 Node.js、ASP.NET 和 Go 語言）中用做彩蛋。

420 Enhance Your Caim

Twitter Search 與 Trends API 在客戶端被限速的狀況下返回。

421 Misdirected Request （RFC 7540）

該請求針對的是沒法產生響應的服務器（例如由於鏈接重用）。

422 Unprocessable Entity（WebDAV；RFC 4918 ）

請求格式正確，可是因爲含有語義錯誤，沒法響應。

423 Locked（WebDAV；RFC 4918）

當前資源被鎖定。

424 Failed Dependency（WebDAV；RFC 4918）

因爲以前的某個請求發生的錯誤，致使當前請求失敗，例如 PROPPATCH。

425 Unordered Collection

在 WebDAV Advanced Collections Protocol 中定義，但 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol 中並不存在。

426 Upgrade Required（RFC 2817）

客戶端應當切換到TLS/1.0，並在HTTP/1.1 Upgrade header中給出。

428 Precondition Required (RFC 6585)

原服務器要求該請求知足必定條件。這是爲了防止「‘未更新’問題，即客戶端讀取（GET）一個資源的狀態，更改它，並將它寫（PUT）回服務器，但這期間第三方已經在服務器上更改了該資源的狀態，所以致使了衝突。」

429 Too Many Requests （RFC 6585）

用戶在給定的時間內發送了太多的請求。旨在用於網絡限速。

431 Request Header Fields Too Large （RFC 6585）

服務器不肯處理請求，由於一個或多個頭字段過大。

444 No Response

Nginx 上 HTTP 服務器擴展。服務器不向客戶端返回任何信息，並關閉鏈接（有助於阻止惡意軟件）。

450 Blocked by Windows Parental Controls

這是一個由 Windows 家庭控制（Microsoft）HTTP 阻止的 450 狀態代碼的示例，用於信息和測試。

451 Unavailable For Legal Reasons

該訪問因法律的要求而被拒絕，由 IETF 在 2015 覈准後新增長。

494 Request Header Too Large

在錯誤代碼 431 提出以前 Nginx 上使用的擴展 HTTP 代碼。

5xx 服務器錯誤

表示服務器沒法完成明顯有效的請求。這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生，也有多是服務器意識到以當前的軟硬件資源沒法完成對請求的處理。除非這是一個 HEAD 請求，不然服務器應當包含一個解釋當前錯誤狀態以及這個情況是臨時的仍是永久的解釋信息實體。瀏覽器應當向用戶展現任何在當前響應中被包含的實體。這些狀態碼適用於任何響應方法。

500 Internal Server Error

通用錯誤消息，服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。沒有給出具體錯誤信息。

501 Not Implemented

服務器不支持當前請求所須要的某個功能。當服務器沒法識別請求的方法，而且沒法支持其對任何資源的請求。（例如，網絡服務API的新功能）

502 Bad Gateway

做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。

503 Service Unavailable

因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。這個情況是暫時的，而且將在一段時間之後恢復。若是可以預計延遲時間，那麼響應中能夠包含一個 Retry-After 頭用以標明這個延遲時間。若是沒有給出這個 Retry-After 信息，那麼客戶端應當以處理 500 響應的方式處理它。

504 Gateway Timeout

做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI 標識出的服務器，例如 HTTP、FTP、LDAP）或者輔助服務器（例如 DNS）收到響應。

注意：某些代理服務器在 DNS 查詢超時時會返回 400 或者 500 錯誤。

505 HTTP Version Not Supported

服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。這暗示着服務器不能或不肯使用與客戶端相同的版本。響應中應當包含一個描述了爲什麼版本不被支持以及服務器支持哪些協議的實體。

506 Variant Also Negotiates（RFC 2295）

由《透明內容協商協議》（RFC 2295）擴展，表明服務器存在內部配置錯誤，被請求的協商變元資源被配置爲在透明內容協商中使用本身，所以在一個協商處理中不是一個合適的重點。

507 Insufficient Storage（WebDAV；RFC 4918）

服務器沒法存儲完成請求所必須的內容。這個情況被認爲是臨時的。

508 Loop Detected （WebDAV；RFC 5842）

服務器在處理請求時陷入死循環。 （可代替 208 狀態碼）

510 Not Extended（RFC 2774）

獲取資源所須要的策略並無被知足。

511 Network Authentication Required （RFC 6585）

客戶端須要進行身份驗證才能得到網絡訪問權限，旨在限制用戶羣訪問特定網絡（例如鏈接 WiFi 熱點時的強制網絡門戶）。