柚子快報(bào)激活碼778899分享：Postman使用-基礎(chǔ)篇

http://yzkb.51969.com/

前言

本教程將結(jié)合業(yè)界廣為推崇和使用的RestAPI設(shè)計(jì)典范Github API，詳細(xì)介紹Postman接口測(cè)試工具的使用方法和實(shí)戰(zhàn)技巧。

在開(kāi)始這個(gè)教程之前，先聊一下為什么接口測(cè)試在現(xiàn)軟件行業(yè)如此重要？ 為什么我們要學(xué)習(xí)Postman？

現(xiàn)代軟件行業(yè)已經(jīng)從傳統(tǒng)的萬(wàn)維網(wǎng)發(fā)展到移動(dòng)互聯(lián)網(wǎng)，云計(jì)算，如今更進(jìn)入到萬(wàn)物互聯(lián)時(shí)代。軟件和網(wǎng)絡(luò)會(huì)連接我們生活的方方面面，不同的設(shè)備，不同的軟件系統(tǒng)之間存在各式各樣的聯(lián)系。而接口就是不同設(shè)備、系統(tǒng)之間聯(lián)系的橋梁，所以接口在現(xiàn)今和未來(lái)的軟硬件產(chǎn)業(yè)當(dāng)中都具有越來(lái)越高的重要性和地位。

什么是接口？

IT行業(yè)從WWW萬(wàn)維網(wǎng)時(shí)代的C/S，B/S架構(gòu)，到移動(dòng)互聯(lián)網(wǎng)時(shí)代的大前端時(shí)代，發(fā)展到云計(jì)算時(shí)代以IaaS（基礎(chǔ)架構(gòu)即服務(wù)），PaaS（平臺(tái)即服務(wù)），SaaS（軟件即服務(wù)）為代表的云端架構(gòu)，如今更是進(jìn)入到萬(wàn)物互聯(lián)的物聯(lián)網(wǎng)時(shí)代，網(wǎng)絡(luò)連接著我們生活的方方面面，而承載這些連接的連接點(diǎn)，就是網(wǎng)絡(luò)接口，接口是不同網(wǎng)絡(luò)應(yīng)用之間聯(lián)系、交互、相互作用的入口和橋梁。

如下圖，是接口在軟件系統(tǒng)中所處位置的示意圖 這里UI接口和API接口分別代表用戶交互接口和應(yīng)用程序接口

接口測(cè)試

了解了接口的概念，我們?cè)倏词裁词墙涌跍y(cè)試？

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

接口測(cè)試是測(cè)試系統(tǒng)組件間接口的一種測(cè)試。接口測(cè)試主要用于檢測(cè)外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個(gè)子系統(tǒng)之間的交互點(diǎn)。測(cè)試的重點(diǎn)是要檢查數(shù)據(jù)的交換，傳遞和控制管理過(guò)程，以及系統(tǒng)間的相互邏輯依賴關(guān)系等。

可以看到，針對(duì)接口定義闡述后，說(shuō)明了接口測(cè)試的重點(diǎn)包括交互的數(shù)據(jù)、過(guò)程以及背后的業(yè)務(wù)邏輯。

再進(jìn)一步看更常用的API測(cè)試的定義，這個(gè)百度沒(méi)有收錄，可以看下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]

它是直接針對(duì)API進(jìn)行測(cè)試的一類(lèi)集成測(cè)試，注意wiki把接口測(cè)試歸類(lèi)在集成測(cè)試階段。也就是說(shuō)它更多是在系統(tǒng)集成時(shí)實(shí)施。然后也說(shuō)明了接口測(cè)試不單純是功能測(cè)試，還需考慮可靠性、安全、性能等。API接口測(cè)試和GUI測(cè)試不同，更多體現(xiàn)在消息層，并且因?yàn)镚UI層在自動(dòng)化測(cè)試上的先天劣勢(shì)，API自動(dòng)化目前是自動(dòng)化測(cè)試領(lǐng)域以及敏捷、DevOps等研發(fā)模式的關(guān)鍵實(shí)踐。

下圖是著名的測(cè)試金字塔，它根據(jù)不同測(cè)試類(lèi)型對(duì)軟件測(cè)試進(jìn)行了分層，底層是針對(duì)的代碼層面的單元測(cè)試，中間是service服務(wù)測(cè)試，而現(xiàn)今的應(yīng)用服務(wù)更多是API形式來(lái)體現(xiàn)，服務(wù)測(cè)試也可以理解為API的測(cè)試，上層則是針對(duì)用戶界面的GUI測(cè)試。

這個(gè)模型體現(xiàn)出在自動(dòng)化測(cè)試中，越底層的自動(dòng)化測(cè)試所占比重應(yīng)該越大，才有更好的投入產(chǎn)出比。中間這一層的API測(cè)試它既不像UI層那樣維護(hù)成本巨大，很難跟上快速迭代的要求，同時(shí)它又比單元測(cè)試更能在業(yè)務(wù)邏輯上進(jìn)行質(zhì)量驗(yàn)證。所以現(xiàn)在一般認(rèn)為API測(cè)試是自動(dòng)化測(cè)試實(shí)施上的優(yōu)先選擇

HTTP協(xié)議基礎(chǔ)

在正式開(kāi)始Postman的功能介紹前，首先還是要介紹Postman的測(cè)試對(duì)象。Postman主要是針對(duì)HTTP協(xié)議接口的測(cè)試工具，所以本章首先介紹一下HTTP協(xié)議的基礎(chǔ)知識(shí)。

HTTP，即超文本傳輸協(xié)議（HyperText Transfer Protocol)，是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，目前主要使用的1.1版本，基于TCP/IP通信協(xié)議來(lái)傳遞數(shù)據(jù)(HTML，文件、數(shù)據(jù)、API接口消息等)

http協(xié)議工作于客戶端-服務(wù)器即C/S架構(gòu)上

HTTP消息組成

客戶端發(fā)送一個(gè)HTTP請(qǐng)求到服務(wù)器，請(qǐng)求消息包括以下格式：

請(qǐng)求行（request line）、請(qǐng)求頭部（header）、空行和請(qǐng)求數(shù)據(jù)四個(gè)部分。如圖

如下是一個(gè)請(qǐng)求百度首頁(yè)的請(qǐng)求示例：

GET https://www.baidu.com/ HTTP/1.1

#請(qǐng)求方法 URL HTTP協(xié)議版本

Host: www.baidu.com

#請(qǐng)求服務(wù)器地址

#以下是消息頭內(nèi)容

Connection: keep-alive

#連接方式：長(zhǎng)連接

Cache-Control: max-age=0

#請(qǐng)求緩存控制，需確認(rèn)請(qǐng)求內(nèi)容是否有修改

Upgrade-Insecure-Requests: 1

#支持https協(xié)議

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

#請(qǐng)求客戶端，瀏覽器版本

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

#支持的響應(yīng)內(nèi)容類(lèi)型

Accept-Encoding: gzip, deflate, br

#支持的編碼類(lèi)型

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

#支持的語(yǔ)言

Cookie: BAIDUID=C0A2...

#攜帶的cookie信息

#未攜帶請(qǐng)求消息體，body為空

服務(wù)器接收并處理客戶端發(fā)過(guò)來(lái)的請(qǐng)求，返回一個(gè)HTTP的響應(yīng)消息。也由四個(gè)部分組成，分別是：

響應(yīng)狀態(tài)行、消息報(bào)頭、空行和響應(yīng)正文。 如圖

如下是百度首頁(yè)的響應(yīng)示例

HTTP/1.1 200 OK

#協(xié)議版本 消息狀態(tài)碼 狀態(tài)描述

Bdpagetype: 2

Bdqid: 0x8707d7d80001f34e

#自定義消息頭

Cache-Control: private

#緩存控制策略

Connection: Keep-Alive

#長(zhǎng)連接

Content-Type: text/html;charset=utf-8

#響應(yīng)內(nèi)容類(lèi)型

Date: Sat, 22 Dec 2018 08:54:51 GMT

#響應(yīng)時(shí)間

Expires: Sat, 22 Dec 2018 08:54:51 GMT

#過(guò)期失效時(shí)間

Server: BWS/1.1

#服務(wù)器系統(tǒng)及版本

Set-Cookie: BDSVRTM=372; path=/

Set-Cookie: BD_HOME=1; path=/

Set-Cookie: path=/; domain=.baidu.com

#設(shè)置客戶端cookie

Strict-Transport-Security: max-age=172800

#嚴(yán)格安全傳輸，有效時(shí)間

X-Ua-Compatible: IE=Edge,chrome=1

#兼容瀏覽器版本

Content-Length: 191722

#消息體長(zhǎng)度

#以下消息體內(nèi)容

...

HTTP方法

HTTP方法是請(qǐng)求消息中攜帶的關(guān)鍵信息，告知服務(wù)器本次請(qǐng)求希望進(jìn)行的操作類(lèi)型。目前在HTTP1.1版本中常見(jiàn)以下方法

No.方法描述1GET請(qǐng)求指定的頁(yè)面信息，并返回實(shí)體主體。2HEAD類(lèi)似于get請(qǐng)求，只不過(guò)返回的響應(yīng)中沒(méi)有具體的內(nèi)容，用于獲取報(bào)頭3POST向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。4PUT從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。5DELETE請(qǐng)求服務(wù)器刪除指定的頁(yè)面。6CONNECTHTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。7TRACE回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。8PATCH從客戶端向服務(wù)器傳送數(shù)據(jù)，取代指定文檔的部分內(nèi)容

HTTP狀態(tài)碼

HTTP狀態(tài)碼定義了服務(wù)器端處理HTTP請(qǐng)求的結(jié)果信息，主要包含以下五類(lèi)：

狀態(tài)碼描述1XX已接收，待處理2XX請(qǐng)求處理成功3XX重定向，資源位置發(fā)生變化4XX客戶端請(qǐng)求信息錯(cuò)誤5XX服務(wù)端處理發(fā)生錯(cuò)誤

1xx 消息

這一類(lèi)型的狀態(tài)碼，代表請(qǐng)求已被接受，需要繼續(xù)處理。這類(lèi)響應(yīng)是臨時(shí)響應(yīng)，只包含狀態(tài)行和某些可選的響應(yīng)頭信息，并以空行結(jié)束。由于HTTP/1.0協(xié)議中沒(méi)有定義任何1xx狀態(tài)碼，所以除非在某些試驗(yàn)條件下，服務(wù)器禁止向此類(lèi)客戶端發(fā)送1xx響應(yīng)。[4] 這些狀態(tài)碼代表的響應(yīng)都是信息性的，標(biāo)示客戶應(yīng)該采取的其他行動(dòng)。

2xx 成功

這一類(lèi)型的狀態(tài)碼，代表請(qǐng)求已成功被服務(wù)器接收、理解、并接受。

3xx 重定向

這類(lèi)狀態(tài)碼代表需要客戶端采取進(jìn)一步的操作才能完成請(qǐng)求。通常，這些狀態(tài)碼用來(lái)重定向，后續(xù)的請(qǐng)求地址（重定向目標(biāo)）在本次響應(yīng)的Location域中指明。

4xx 客戶端錯(cuò)誤

這類(lèi)的狀態(tài)碼代表了客戶端看起來(lái)可能發(fā)生了錯(cuò)誤，妨礙了服務(wù)器的處理。除非響應(yīng)的是一個(gè)HEAD請(qǐng)求，否則服務(wù)器就應(yīng)該返回一個(gè)解釋當(dāng)前錯(cuò)誤狀況的實(shí)體，以及這是臨時(shí)的還是永久性的狀況。這些狀態(tài)碼適用于任何請(qǐng)求方法。瀏覽器應(yīng)當(dāng)向用戶顯示任何包含在此類(lèi)錯(cuò)誤響應(yīng)中的實(shí)體內(nèi)容

5xx 服務(wù)器錯(cuò)誤

表示服務(wù)器無(wú)法完成明顯有效的請(qǐng)求。這類(lèi)狀態(tài)碼代表了服務(wù)器在處理請(qǐng)求的過(guò)程中有錯(cuò)誤或者異常狀態(tài)發(fā)生，也有可能是服務(wù)器意識(shí)到以當(dāng)前的軟硬件資源無(wú)法完成對(duì)請(qǐng)求的處理。除非這是一個(gè)HEAD請(qǐng)求，否則服務(wù)器應(yīng)當(dāng)包含一個(gè)解釋當(dāng)前錯(cuò)誤狀態(tài)以及這個(gè)狀況是臨時(shí)的還是永久的解釋信息實(shí)體。瀏覽器應(yīng)當(dāng)向用戶展示任何在當(dāng)前響應(yīng)中被包含的實(shí)體。這些狀態(tài)碼適用于任何響應(yīng)方法。

詳細(xì)的狀態(tài)碼清單可參見(jiàn)附錄

GitHub API

本教程后續(xù)將主要使用Github API作為實(shí)戰(zhàn)介紹API。 本章會(huì)簡(jiǎn)要介紹Github網(wǎng)站以及Github API。

GitHub 是一個(gè)面向開(kāi)源及私有軟件項(xiàng)目的托管平臺(tái)，因?yàn)橹恢С?Git 作為唯一的版本庫(kù)格式進(jìn)行托管，故名 GitHub。也是目前全球最大的代碼托管平臺(tái)，可以說(shuō)是程序員的圣地，號(hào)稱(chēng)全球最大的同性交友平臺(tái)? (Github 國(guó)內(nèi)有時(shí)會(huì)間歇性無(wú)法訪問(wèn)，可能需要科學(xué)上網(wǎng))

github 中的一些主要概念

提交（commit）：提交更改到倉(cāng)庫(kù)（本地Git倉(cāng)庫(kù)與GitHub倉(cāng)庫(kù)是兩碼事）。提交信息（commit message）：每次提交的時(shí)候，需要提供一個(gè)信息，描述這次提交都做了什么。分支（branch）：像樹(shù)狀圖一樣，每個(gè)獨(dú)立的分支都是項(xiàng)目的一個(gè)版本，分支都可以與master合并。主分支（master branch）：所有的Git項(xiàng)目在最初創(chuàng)建時(shí)，都會(huì)默認(rèn)創(chuàng)建出一個(gè)分支，這就是主分支。在開(kāi)發(fā)中，寫(xiě)一個(gè)新功能的時(shí)候，都是先建立一個(gè)分支，在該分支上完成功能并測(cè)試，通過(guò)后由項(xiàng)目leader將該分支merge到master上。功能分支（feature branch）：沒(méi)怎么用過(guò)發(fā)布分支（release branch）：如果有一個(gè)手動(dòng)QA（質(zhì)量管理）流程，或者必須要支持舊版本的軟件時(shí)，需要一個(gè)發(fā)布分支來(lái)存放必要的補(bǔ)丁與更新記錄。功能分支和發(fā)布分支沒(méi)技術(shù)區(qū)別，只是在團(tuán)隊(duì)間討論的時(shí)候，有助于區(qū)分類(lèi)別。合并（merge）：merge可以將一個(gè)分支上的全部?jī)?nèi)容歸并到另一個(gè)分支上，一般就是將分支merge到主分支。標(biāo)簽（tag）：常用于記錄發(fā)布版本，在版本發(fā)布的時(shí)候，給一個(gè)tag，這樣就能夠記錄該版本的代碼是何時(shí)生成的。查看（check out）：一般就是查看某一個(gè)分支上操作的記錄。拉?。╬ull request）：一般用來(lái)從遠(yuǎn)程倉(cāng)庫(kù)拉取分支中的代碼到本地，也可以從本地倉(cāng)庫(kù)中拉取分支代碼到當(dāng)前工程中。提出問(wèn)題（issue）：GitHub的提出問(wèn)題的功能，一般遇到問(wèn)題，可以將出現(xiàn)問(wèn)題的場(chǎng)合，通過(guò)issue的方式記錄。維基（WIKI）：一個(gè)輕量級(jí)的Web頁(yè)面創(chuàng)建方式，創(chuàng)建的Web頁(yè)面之間可以通過(guò)鏈接互相聯(lián)系。GitHub中的項(xiàng)目通常使用WIKi進(jìn)行文檔記錄?？寺。╟lone）：從GitHub上下載一個(gè)副本到本地，操作后可以pull上去。分叉（fork）：A復(fù)制一個(gè)B的項(xiàng)目到自己的賬戶下，修改后再提交，B能看到A修改的內(nèi)容，但是B原本的項(xiàng)目是不會(huì)有變動(dòng)的。

github 主界面功能

圖片轉(zhuǎn)自george_zyf的博客

Github API

目前Github API最新的V4版本是基于GraphQL的API，但常用的還是V3的Restful API

github API中幾類(lèi)主要資源及對(duì)應(yīng)操作

User 資源

Repo 操作

issue 操作

圖片來(lái)自網(wǎng)絡(luò)

github 中的時(shí)間格式

github 中時(shí)間格式如下：

YYYY-MM-DDTHH:MM:SSZ

github 限流規(guī)則

github 為包含服務(wù)端負(fù)載壓力，會(huì)對(duì)請(qǐng)求流量進(jìn)行限制。在每個(gè) github 的響應(yīng)消息頭中都會(huì)攜帶 github 的限流設(shè)置。

頭參數(shù)含義X-RateLimit-Limit當(dāng)前每小時(shí)最大請(qǐng)求限制，一般未鑒權(quán)請(qǐng)求60次，鑒權(quán)請(qǐng)求5000次X-RateLimit-Remaining當(dāng)前剩余請(qǐng)求次數(shù)X-RateLimit-Reset剩余限制重置時(shí)間，毫秒

請(qǐng)求參數(shù)與分頁(yè)

請(qǐng)求中可以攜帶參數(shù)，一般包含兩種參數(shù): 路徑參數(shù)和查詢參數(shù)

github API中默認(rèn)支持兩個(gè)分頁(yè)參數(shù)：

page 當(dāng)前顯示頁(yè)數(shù)per_page 每頁(yè)顯示結(jié)果數(shù)

Postman 基礎(chǔ)

可以用于Rest接口測(cè)試的測(cè)試工具非常多，常見(jiàn)的有soapUI、Jmeter、fiddler等都經(jīng)常用來(lái)做接口測(cè)試。但是目前在接口測(cè)試人員中最流行，最常見(jiàn)還是本章向大家介紹的Postman。

Postman 的安裝

Postman最早的版本，以及很長(zhǎng)一段時(shí)間都是以Chrome插件的形式存在的。以至很多人甚至認(rèn)為postman就是google的官方工具插件，我們目前能看到的大量資料也都是基于chrome的插件形式來(lái)進(jìn)行介紹的。

但是目前Postman其實(shí)已經(jīng)推出了獨(dú)立的本地App程序，并且官方已經(jīng)宣布不再支持chrome的插件形式。雖然插件版本現(xiàn)在還能使用，可是畢竟相比Native版本，受限于chrome瀏覽器的功能，很多功能在插件版本中是欠缺的，比如cookie的內(nèi)建支持，代理功能，控制臺(tái)功能等等。所以此處就不再介紹插件版本的安裝。

本地版本的安裝，其實(shí)也非常簡(jiǎn)單。從官網(wǎng)根據(jù)自己操作系統(tǒng)的類(lèi)型選擇相應(yīng)的版本下載即可。

這里還有一點(diǎn)要注意下，在postman的官網(wǎng)，我們最好注冊(cè)一個(gè)賬號(hào)，后續(xù)在使用postman的時(shí)候很多高級(jí)功能需要用這個(gè)賬號(hào)登錄后才可以使用。

安裝完成，在桌面上出現(xiàn)Postman那個(gè)pose很帥的小人圖標(biāo)，則安裝完成。

Postman 主界面

打開(kāi)Postman進(jìn)入，首次會(huì)提示選擇希望創(chuàng)建的任務(wù)類(lèi)型。

這里有六種任務(wù)類(lèi)型，我們?cè)傧旅娴膶?shí)戰(zhàn)中都會(huì)詳細(xì)講解，這里先簡(jiǎn)單說(shuō)明一下：

Request是Postman軟件的基礎(chǔ)和核心，也就是通過(guò)這個(gè)功能來(lái)創(chuàng)建request請(qǐng)求，完成接口測(cè)試的核心工作。Collection其實(shí)是個(gè)集合，我們可以認(rèn)為是一批Request請(qǐng)求的集合，或者說(shuō)測(cè)試集。它也是Postman一些進(jìn)階功能的基本單位Environment，字面理解就是環(huán)境，其實(shí)可以認(rèn)為是一些配置變量的集合，實(shí)際應(yīng)用中可以起到通過(guò)不同配置區(qū)分不同測(cè)試環(huán)境的效果 后面這三個(gè)都是Postman的高級(jí)功能API documention，是通過(guò)我們調(diào)試通過(guò)的request來(lái)自動(dòng)生成接口文檔，便于團(tuán)隊(duì)的共享和接口的交付。Mock server 在我們進(jìn)行接口測(cè)試或開(kāi)發(fā)的時(shí)候，很多時(shí)候是需要模擬對(duì)端的接口服務(wù)器的，Mock server就起到的模擬服務(wù)器端的作用。Monitor 這是個(gè)監(jiān)控功能，通過(guò)monitor我可以監(jiān)控我的接口是不是正常。說(shuō)白了，這其實(shí)就是個(gè)定時(shí)的接口執(zhí)行功能。

大致了解下幾種不同的任務(wù)類(lèi)型，我們先關(guān)掉這個(gè)界面，我們?cè)賮?lái)看看主界面的功能區(qū)間

Banner 區(qū)域

首先是上面的菜單欄，對(duì)應(yīng)功能區(qū)的各項(xiàng)功能，在菜單欄上都能找到對(duì)應(yīng)的菜單。然后是下面的banner區(qū)域。 從左到右依次介紹：

會(huì)打開(kāi)啟動(dòng)時(shí)的創(chuàng)建窗口，用于創(chuàng)建六種類(lèi)型的任務(wù)。

按鈕，可以用于導(dǎo)入外部文件，外部文件可以是postman的Collection格式文件，數(shù)據(jù)文件，以及其他的API定義文件

則會(huì)啟動(dòng)Collection runner，它是一個(gè)運(yùn)行器，用于運(yùn)行已經(jīng)建立的測(cè)試任務(wù)。我們后面會(huì)有詳細(xì)介紹

第四個(gè)按鈕，可以新建tab，或者多開(kāi)一個(gè)postman程序，或者runer程序。

中間是選擇使用的workspace，但這個(gè)需要賬號(hào)登錄，會(huì)同步云端的workspace設(shè)置。每個(gè)賬號(hào)會(huì)有一個(gè)默認(rèn)的workspace，workspace它是一個(gè)工作空間，大家可以理解成類(lèi)似項(xiàng)目或者工程。

banner條右側(cè)還有幾個(gè)按鈕

第一個(gè)是同步，也是在有賬號(hào)的情況下，可以在多個(gè)電腦間同步workspace內(nèi)的相關(guān)接口測(cè)試設(shè)計(jì)。第二個(gè)proxy，則類(lèi)似前面介紹過(guò)的fiddler，提供代理抓取API功能。當(dāng)然這個(gè)功能postman不像Fiddler那樣豐富第三個(gè)按鈕包括setting以及文檔指南。 setting里是軟件的本地配置第四個(gè)按鈕是消息通知，很好理解，會(huì)顯示一些提醒信息然后是postman的twitter，在墻后面就不要去看了最后是登錄，可以用postman的賬號(hào)的登錄

Setting 設(shè)置

Postman 工具的使用屬性和應(yīng)用設(shè)置我們可以在Setting 中國(guó)進(jìn)行設(shè)置。以下分別說(shuō)明：

General

Themes

Shortcuts

工具快捷鍵

Data

工具數(shù)據(jù)導(dǎo)入導(dǎo)出

add-ons

Newman 插件下載方法

Sync

同步設(shè)置

certificates

本地證書(shū)設(shè)置

Proxy

本地網(wǎng)絡(luò)代理設(shè)置

update

升級(jí)設(shè)置

about

工具**關(guān)于…**等版本信息

左側(cè)邊欄

filter篩選欄，篩選顯示不同的消息history是操作消息記錄清單collection如前面介紹，顯示請(qǐng)求集合

底邊狀態(tài)欄

最左面，顯示和關(guān)閉左側(cè)邊欄然后是搜索功能，這個(gè)容易理解第三個(gè)是控制臺(tái)，可以在這里看到消息相互的詳細(xì)信息

用戶指南調(diào)整功能區(qū)顯示樣式快捷鍵清單參考幫助相關(guān)的連接

主功能區(qū)

主要包括上下兩部分，上面是request區(qū)，下面是response區(qū)。也可以分成左右顯示。

Request區(qū)域

request部分默認(rèn)開(kāi)啟了一個(gè)選項(xiàng)卡，可以新開(kāi)多個(gè)選項(xiàng)卡便于同時(shí)編輯。

默認(rèn)使用的是GET方法，這也是使用最多的HTTP方法，下拉可以選擇其他的方法，常用的還有哪些？ POST、PUT、Delete等。

URL部分輸入請(qǐng)求的地址。比如我們輸入GithubAPI的根地址。

param是參數(shù)管理界面，在這里我們可以添加參數(shù)（有key-value，塊編輯模式）。

Send發(fā)送請(qǐng)求，小箭頭下send and download，會(huì)在發(fā)送以后把響應(yīng)消息導(dǎo)出成json保存。旁邊的save，保存功能，其實(shí)是把這個(gè)request作為一個(gè)case保存到collection里。

鑒權(quán)部分，雖然request編輯器已經(jīng)足夠強(qiáng)大可以處理鑒權(quán)消息，但是很多時(shí)候鑒權(quán)是個(gè)使用頻率很高的功能，所以Postman單獨(dú)把鑒權(quán)部分抽取出來(lái)，并且封裝了目前的絕大部分鑒權(quán)方式

繼承，默認(rèn)鑒權(quán)方式不鑒權(quán)bearer token鑒權(quán)，一般也叫Json web token，其實(shí)就是發(fā)送一個(gè)json格式的token令牌，服務(wù)端會(huì)針對(duì)token進(jìn)行解密驗(yàn)證Basic Auth基礎(chǔ)驗(yàn)證，提供用戶名密碼驗(yàn)證，postman 會(huì)自動(dòng)生成authorization，常用鑒權(quán)方式digest auth，摘要式認(rèn)證 在基本身份認(rèn)證上面擴(kuò)展了安全性，服務(wù)器為每一個(gè)連接生成一個(gè)唯一的隨機(jī)數(shù)，客戶端用這個(gè)隨機(jī)數(shù)對(duì)密碼進(jìn)行MD5加密，然后返回服務(wù)器，服務(wù)器也用這個(gè)隨機(jī)數(shù)對(duì)密碼進(jìn)行加密，然后和客戶端傳送過(guò)來(lái)的加密數(shù)據(jù)進(jìn)行比較,如果一致就返回結(jié)果。 它是一個(gè)二次驗(yàn)證的過(guò)程，會(huì)有兩次認(rèn)證交互消息 客戶端請(qǐng)求資源->服務(wù)器返回認(rèn)證標(biāo)示->客戶端發(fā)送認(rèn)證信息->服務(wù)器查驗(yàn)認(rèn)證Oauth，一般用于第三方認(rèn)證，有1,2兩個(gè)版本，需要提供的信息不太一樣。也是常用的鑒權(quán)方式Hawk 認(rèn)證，是另一種認(rèn)證方案，采用的叫消息碼認(rèn)證算法，和Digest認(rèn)證類(lèi)似，它也是需要二次交互的AWS簽名認(rèn)證，是針對(duì)亞馬遜的AWS公有云用戶簽名的認(rèn)證方式NTLM是微軟的局域網(wǎng)管理認(rèn)證協(xié)議

大家有個(gè)基本了解即可，一般比較常用的就是basic以及OAuth2了。

header就是消息頭管理，可以定義頭部信息。

Body，請(qǐng)求消息體。一般Post、put、patch等會(huì)更新內(nèi)容的請(qǐng)求才會(huì)攜帶消息體，

旁邊pre-script，是指在請(qǐng)求發(fā)送前，可以做一些預(yù)處理的工作，類(lèi)似junit等單元測(cè)試框架中的setup方法，支持js腳本語(yǔ)法

Test則是在響應(yīng)以后，對(duì)響應(yīng)進(jìn)行校驗(yàn)或其他處理的，類(lèi)似junit框架中的teardown方法，同樣支持js腳本語(yǔ)法

cookie管理postman本地cookie信息

code是一個(gè)方便程序員的功能，可以自動(dòng)將接口請(qǐng)求轉(zhuǎn)化成相關(guān)語(yǔ)言編碼，可以看到支持的語(yǔ)言非常豐富，基本涵蓋了各種主流編程語(yǔ)言。

Response區(qū)域

響應(yīng)消息右上角是狀態(tài)碼，懸?？梢钥吹皆敿?xì)解釋。另外是響應(yīng)時(shí)間（從發(fā)出請(qǐng)求到返回客戶端接收的時(shí)間），以及消息大?。ê㈩^和消息體）。

響應(yīng)body部分，即消息體。包括以下幾個(gè)按鈕

pretty，可以根據(jù)表現(xiàn)類(lèi)型進(jìn)行格式化顯示，默認(rèn)json，如果是其他格式類(lèi)型，可以選擇對(duì)應(yīng)形式進(jìn)行格式化。Raw則是未格式化的形式preview則是預(yù)覽，就是在瀏覽器里渲染后呈現(xiàn)的樣子，比如返回的是html就很直觀。旁邊是自動(dòng)換行按鈕。

右邊是拷貝到剪切板和查詢按鈕（正則，大小寫(xiě)敏感、全詞匹配）

其他的幾個(gè)tab：

cookie：響應(yīng)消息的cookie信息header：響應(yīng)消息的header頭部信息Test Results：在請(qǐng)求中添加test Script后，這里會(huì)顯示測(cè)試腳本的校驗(yàn)結(jié)果

Postman中完成Github鑒權(quán)

從Github API文檔中，我們可以看到Github API支持多種鑒權(quán)方式

Basic authentication

curl -u "username" https://api.github.com

這是基本鑒權(quán)方式

OAuth2 token (sent in a header)

curl -H "Authorization: token OAUTH-TOKEN" https://api.github.com

也支持通過(guò)在Header中攜帶Oauth2的token進(jìn)行鑒權(quán)。在github用戶設(shè)置中可以生成這個(gè)token。

個(gè)人設(shè)置 > Settings > Developer settings > Personal access tokens 生成后會(huì)獲得一個(gè)token字串

OAuth2 token (sent as a parameter)

curl https://api.github.com/?access_token=OAUTH-TOKEN

或者通過(guò)在URL中攜帶token參數(shù)鑒權(quán)。

Postman中，可以在Collection中設(shè)置鑒權(quán) 在具體的請(qǐng)求消息中，可以選擇Inherit auth from parent，即繼承上一層的鑒權(quán)。發(fā)送請(qǐng)求后，可以看到已經(jīng)在header中攜帶了鑒權(quán)的token信息

根據(jù)Github API的定義，對(duì)于請(qǐng)求有訪問(wèn)限制，即未鑒權(quán)的請(qǐng)求限制訪問(wèn)為每分鐘60次，對(duì)于已鑒權(quán)的請(qǐng)求訪問(wèn)每分鐘5000次。

我們從響應(yīng)消息的消息頭中可以看到這個(gè)設(shè)置，如：

X-RateLimit-Limit →5000

X-RateLimit-Remaining →4999

X-RateLimit-Reset →1546528838

Postman實(shí)現(xiàn)基本HTTP方法

再來(lái)看如何在Postman中實(shí)現(xiàn)常用的HTTP方法。還是以GithubAPI為例：

GET方法 - 獲取Repo信息

GET /repos/:owner/:repo

這里是獲取Github上Repo信息的API，這里有兩個(gè)路徑參數(shù)，owner代表用戶賬號(hào)，repo指需要獲取的repo信息。 如圖是在postman中設(shè)置路徑參數(shù)的方法。

POST方法 - 創(chuàng)建Repo

創(chuàng)建Repo的示例(https://developer.github.com/v3/repos/#create)

POST /user/repos

這里是一個(gè)創(chuàng)建hello world的Repo的請(qǐng)求消息體示例

{

"name": "Hello-World",

"description": "This is your first repository",

"homepage": "https://github.com",

"private": false,

"has_issues": true,

"has_projects": true,

"has_wiki": true

}

這里name是必填字段，其他是repo的屬性設(shè)置。 在Postman中如圖提交，返回狀態(tài)碼201 created，即可創(chuàng)建一個(gè)Hello world的Repo

在Github中，可以看到賬號(hào)下新增了一個(gè)hello world的repo，并且包含有已設(shè)置的issue、projects、wiki這幾個(gè)欄目

PATCH方法 - 修改Repo

GitHub可以通過(guò)PATCH方法來(lái)對(duì)Repo進(jìn)行修改.PATCH方法和PUT方法都是update的修改方法，但PATCH方法更多用在部分修改的場(chǎng)景下，PUT方法則更多是整體替換。

PATCH /repos/:owner/:repo

比如上例中hello world這個(gè)repo修改Repo中的部分信息，可以去除projects和wiki這兩個(gè)欄目 消息體：

{

"name": "Hello-World",

"description": "This is your first repository",

"homepage": "https://github.com",

"has_projects": false,

"has_wiki": false

}

Postman中如圖：

回到Github，可以看到Repo中對(duì)應(yīng)的欄目已經(jīng)不見(jiàn)了

PUT方法 - 設(shè)置或替換Topic

Topic是Github上Repo的搜索關(guān)鍵字，便于用戶進(jìn)行repo查詢。

PUT /repos/:owner/:repo/topics

Github API設(shè)置topic的api是使用put方法提交一個(gè)topic數(shù)組，如

{

"names": [

"restapi",

"atom",

"chengxiaqiucao"

]

}

這時(shí)在Postman中提交，會(huì)發(fā)現(xiàn)有如下報(bào)錯(cuò)：

這是因?yàn)镚ithub API要求設(shè)置topic時(shí)，需要在header中設(shè)置accept字段,取值：

application/vnd.github.mercy-preview+json

正確設(shè)置后，則可以看到設(shè)置成功,返回200 OK

大家可能會(huì)發(fā)現(xiàn)一個(gè)小bug，當(dāng)設(shè)置的topic存在大寫(xiě)字符時(shí)，會(huì)出現(xiàn)格式報(bào)錯(cuò)。比如大家參照官方示例設(shè)置"API"這樣的topic，會(huì)發(fā)現(xiàn)設(shè)置不成功。大家可以嘗試一下。

DELETE方法 - 刪除Repo

Github API中，使用delete方法可以刪除repo

DELETE /repos/:owner/:repo

刪除成功后，返回204. 此時(shí)再查詢賬號(hào)，應(yīng)該發(fā)現(xiàn)Hello-World這個(gè)repo已經(jīng)被刪除了

結(jié)語(yǔ)及預(yù)告

至此，我們通過(guò)Github API中幾個(gè)實(shí)際的例子，學(xué)習(xí)了如何通過(guò)Postman來(lái)完成一些基本的HTTP方法的請(qǐng)求發(fā)送和響應(yīng)查看，通過(guò)查看結(jié)果狀態(tài)碼或響應(yīng)內(nèi)容來(lái)判斷結(jié)果正確性。

當(dāng)然Postman的功能遠(yuǎn)不止于此，API接口測(cè)試中也還有很多復(fù)雜的場(chǎng)景需要特別處理。 歡迎大家繼續(xù)關(guān)注 《玩轉(zhuǎn)Postman - 進(jìn)階篇》。在進(jìn)階篇中我們將繼續(xù)深入講解Postman的進(jìn)階功能，并結(jié)合一些復(fù)雜的實(shí)例場(chǎng)景來(lái)學(xué)習(xí)：

Postman 的變量類(lèi)型及其作用域環(huán)境與 Collection;Postman 如何通過(guò)內(nèi)建腳本實(shí)現(xiàn)接口預(yù)處理Postman 實(shí)現(xiàn)測(cè)試結(jié)果的腳本校驗(yàn)；如何實(shí)現(xiàn)接口的關(guān)聯(lián)測(cè)試Postman 中的 JavaScript 擴(kuò)展

附錄

HTTP狀態(tài)碼詳解（譯自Wiki百科，目前所見(jiàn)最全面的解釋?zhuān)?/p>

1xx 消息

這一類(lèi)型的狀態(tài)碼，代表請(qǐng)求已被接受，需要繼續(xù)處理。這類(lèi)響應(yīng)是臨時(shí)響應(yīng)，只包含狀態(tài)行和某些可選的響應(yīng)頭信息，并以空行結(jié)束。由于HTTP/1.0協(xié)議中沒(méi)有定義任何1xx狀態(tài)碼，所以除非在某些試驗(yàn)條件下，服務(wù)器禁止向此類(lèi)客戶端發(fā)送1xx響應(yīng)。[4] 這些狀態(tài)碼代表的響應(yīng)都是信息性的，標(biāo)示客戶應(yīng)該采取的其他行動(dòng)。

100 Continue

服務(wù)器已經(jīng)接收到請(qǐng)求頭，并且客戶端應(yīng)繼續(xù)發(fā)送請(qǐng)求主體（在需要發(fā)送身體的請(qǐng)求的情況下：例如，POST請(qǐng)求），或者如果請(qǐng)求已經(jīng)完成，忽略這個(gè)響應(yīng)。服務(wù)器必須在請(qǐng)求完成后向客戶端發(fā)送一個(gè)最終響應(yīng)。要使服務(wù)器檢查請(qǐng)求的頭部，客戶端必須在其初始請(qǐng)求中發(fā)送Expect: 100-continue作為頭部，并在發(fā)送正文之前接收100 Continue狀態(tài)代碼。響應(yīng)代碼417期望失敗表示請(qǐng)求不應(yīng)繼續(xù)。

101 Switching Protocols

服務(wù)器已經(jīng)理解了客戶端的請(qǐng)求，并將通過(guò)Upgrade消息頭通知客戶端采用不同的協(xié)議來(lái)完成這個(gè)請(qǐng)求。在發(fā)送完這個(gè)響應(yīng)最后的空行后，服務(wù)器將會(huì)切換到在Upgrade消息頭中定義的那些協(xié)議。 只有在切換新的協(xié)議更有好處的時(shí)候才應(yīng)該采取類(lèi)似措施。例如，切換到新的HTTP版本（如HTTP/2）比舊版本更有優(yōu)勢(shì)，或者切換到一個(gè)實(shí)時(shí)且同步的協(xié)議（如WebSocket）以傳送利用此類(lèi)特性的資源。

102 Processing（WebDAV；RFC 2518）

WebDAV請(qǐng)求可能包含許多涉及文件操作的子請(qǐng)求，需要很長(zhǎng)時(shí)間才能完成請(qǐng)求。該代碼表示??服務(wù)器已經(jīng)收到并正在處理請(qǐng)求，但無(wú)響應(yīng)可用。[6]這樣可以防止客戶端超時(shí)，并假設(shè)請(qǐng)求丟失。

2xx 成功

這一類(lèi)型的狀態(tài)碼，代表請(qǐng)求已成功被服務(wù)器接收、理解、并接受。

200 OK

請(qǐng)求已成功，請(qǐng)求所希望的響應(yīng)頭或數(shù)據(jù)體將隨此響應(yīng)返回。實(shí)際的響應(yīng)將取決于所使用的請(qǐng)求方法。在GET請(qǐng)求中，響應(yīng)將包含與請(qǐng)求的資源相對(duì)應(yīng)的實(shí)體。在POST請(qǐng)求中，響應(yīng)將包含描述或操作結(jié)果的實(shí)體。

201 Created

請(qǐng)求已經(jīng)被實(shí)現(xiàn)，而且有一個(gè)新的資源已經(jīng)依據(jù)請(qǐng)求的需要而創(chuàng)建，且其URI已經(jīng)隨Location頭信息返回。假如需要的資源無(wú)法及時(shí)創(chuàng)建的話，應(yīng)當(dāng)返回’202 Accepted’。

202 Accepted

服務(wù)器已接受請(qǐng)求，但尚未處理。最終該請(qǐng)求可能會(huì)也可能不會(huì)被執(zhí)行，并且可能在處理發(fā)生時(shí)被禁止。

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

服務(wù)器是一個(gè)轉(zhuǎn)換代理服務(wù)器（transforming proxy，例如網(wǎng)絡(luò)加速器），以200 OK狀態(tài)碼為起源，但回應(yīng)了原始響應(yīng)的修改版本。

204 No Content

服務(wù)器成功處理了請(qǐng)求，沒(méi)有返回任何內(nèi)容。

205 Reset Content

服務(wù)器成功處理了請(qǐng)求，但沒(méi)有返回任何內(nèi)容。與204響應(yīng)不同，此響應(yīng)要求請(qǐng)求者重置文檔視圖。

206 Partial Content（RFC 7233）

服務(wù)器已經(jīng)成功處理了部分GET請(qǐng)求。類(lèi)似于FlashGet或者迅雷這類(lèi)的HTTP 下載工具都是使用此類(lèi)響應(yīng)實(shí)現(xiàn)斷點(diǎn)續(xù)傳或者將一個(gè)大文檔分解為多個(gè)下載段同時(shí)下載。

207 Multi-Status（WebDAV；RFC 4918）

代表之后的消息體將是一個(gè)XML消息，并且可能依照之前子請(qǐng)求數(shù)量的不同，包含一系列獨(dú)立的響應(yīng)代碼。

208 Already Reported （WebDAV；RFC 5842）

DAV綁定的成員已經(jīng)在（多狀態(tài)）響應(yīng)之前的部分被列舉，且未被再次包含。

226 IM Used （RFC 3229）

服務(wù)器已經(jīng)滿足了對(duì)資源的請(qǐng)求，對(duì)實(shí)體請(qǐng)求的一個(gè)或多個(gè)實(shí)體操作的結(jié)果表示。

3xx 重定向

這類(lèi)狀態(tài)碼代表需要客戶端采取進(jìn)一步的操作才能完成請(qǐng)求。通常，這些狀態(tài)碼用來(lái)重定向，后續(xù)的請(qǐng)求地址（重定向目標(biāo)）在本次響應(yīng)的Location域中指明。

當(dāng)且僅當(dāng)后續(xù)的請(qǐng)求所使用的方法是GET或者HEAD時(shí)，用戶瀏覽器才可以在沒(méi)有用戶介入的情況下自動(dòng)提交所需要的后續(xù)請(qǐng)求?？蛻舳藨?yīng)當(dāng)自動(dòng)監(jiān)測(cè)無(wú)限循環(huán)重定向（例如：A→B→C→……→A或A→A），因?yàn)檫@會(huì)導(dǎo)致服務(wù)器和客戶端大量不必要的資源消耗。按照HTTP/1.0版規(guī)范的建議，瀏覽器不應(yīng)自動(dòng)訪問(wèn)超過(guò)5次的重定向。

300 Multiple Choices

被請(qǐng)求的資源有一系列可供選擇的回饋信息，每個(gè)都有自己特定的地址和瀏覽器驅(qū)動(dòng)的商議信息。用戶或?yàn)g覽器能夠自行選擇一個(gè)首選的地址進(jìn)行重定向。 除非這是一個(gè)HEAD請(qǐng)求，否則該響應(yīng)應(yīng)當(dāng)包括一個(gè)資源特性及地址的列表的實(shí)體，以便用戶或?yàn)g覽器從中選擇最合適的重定向地址。這個(gè)實(shí)體的格式由Content-Type定義的格式所決定。瀏覽器可能根據(jù)響應(yīng)的格式以及瀏覽器自身能力，自動(dòng)作出最合適的選擇。當(dāng)然，RFC 2616規(guī)范并沒(méi)有規(guī)定這樣的自動(dòng)選擇該如何進(jìn)行。 如果服務(wù)器本身已經(jīng)有了首選的回饋選擇，那么在Location中應(yīng)當(dāng)指明這個(gè)回饋的URI；瀏覽器可能會(huì)將這個(gè)Location值作為自動(dòng)重定向的地址。此外，除非額外指定，否則這個(gè)響應(yīng)也是可緩存的。

301 Moved Permanently

被請(qǐng)求的資源已永久移動(dòng)到新位置，并且將來(lái)任何對(duì)此資源的引用都應(yīng)該使用本響應(yīng)返回的若干個(gè)URI之一。如果可能，擁有鏈接編輯功能的客戶端應(yīng)當(dāng)自動(dòng)把請(qǐng)求的地址修改為從服務(wù)器反饋回來(lái)的地址。除非額外指定，否則這個(gè)響應(yīng)也是可緩存的。 新的永久性的URI應(yīng)當(dāng)在響應(yīng)的Location域中返回。除非這是一個(gè)HEAD請(qǐng)求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的URI的超鏈接及簡(jiǎn)短說(shuō)明。 如果這不是一個(gè)GET或者HEAD請(qǐng)求，因此瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶的確認(rèn)，因?yàn)檎?qǐng)求的條件可能因此發(fā)生變化。 注意：對(duì)于某些使用HTTP/1.0協(xié)議的瀏覽器，當(dāng)它們發(fā)送的POST請(qǐng)求得到了一個(gè)301響應(yīng)的話，接下來(lái)的重定向請(qǐng)求將會(huì)變成GET方式。

302 Found

要求客戶端執(zhí)行臨時(shí)重定向（原始描述短語(yǔ)為“Moved Temporarily”）。由于這樣的重定向是臨時(shí)的，客戶端應(yīng)當(dāng)繼續(xù)向原有地址發(fā)送以后的請(qǐng)求。只有在Cache-Control或Expires中進(jìn)行了指定的情況下，這個(gè)響應(yīng)才是可緩存的。 新的臨時(shí)性的URI應(yīng)當(dāng)在響應(yīng)的Location域中返回。除非這是一個(gè)HEAD請(qǐng)求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的URI的超鏈接及簡(jiǎn)短說(shuō)明。 如果這不是一個(gè)GET或者HEAD請(qǐng)求，那么瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶的確認(rèn)，因?yàn)檎?qǐng)求的條件可能因此發(fā)生變化。 注意：雖然RFC 1945和RFC 2068規(guī)范不允許客戶端在重定向時(shí)改變請(qǐng)求的方法，但是很多現(xiàn)存的瀏覽器將302響應(yīng)視作為303響應(yīng)，并且使用GET方式訪問(wèn)在Location中規(guī)定的URI，而無(wú)視原先請(qǐng)求的方法。因此狀態(tài)碼303和307被添加了進(jìn)來(lái)，用以明確服務(wù)器期待客戶端進(jìn)行何種反應(yīng)。

303 See Other

對(duì)應(yīng)當(dāng)前請(qǐng)求的響應(yīng)可以在另一個(gè)URI上被找到，當(dāng)響應(yīng)于POST（或PUT / DELETE）接收到響應(yīng)時(shí)，客戶端應(yīng)該假定服務(wù)器已經(jīng)收到數(shù)據(jù)，并且應(yīng)該使用單獨(dú)的GET消息發(fā)出重定向。[23]這個(gè)方法的存在主要是為了允許由腳本激活的POST請(qǐng)求輸出重定向到一個(gè)新的資源。這個(gè)新的URI不是原始資源的替代引用。同時(shí)，303響應(yīng)禁止被緩存。當(dāng)然，第二個(gè)請(qǐng)求（重定向）可能被緩存。 新的URI應(yīng)當(dāng)在響應(yīng)的Location域中返回。除非這是一個(gè)HEAD請(qǐng)求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的URI的超鏈接及簡(jiǎn)短說(shuō)明。 注意：許多HTTP/1.1版以前的瀏覽器不能正確理解303狀態(tài)。如果需要考慮與這些瀏覽器之間的互動(dòng)，302狀態(tài)碼應(yīng)該可以勝任，因?yàn)榇蠖鄶?shù)的瀏覽器處理302響應(yīng)時(shí)的方式恰恰就是上述規(guī)范要求客戶端處理303響應(yīng)時(shí)應(yīng)當(dāng)做的。

304 Not Modified

表示資源未被修改，因?yàn)檎?qǐng)求頭指定的版本If-Modified-Since或If-None-Match。在這種情況下，由于客戶端仍然具有以前下載的副本，因此不需要重新傳輸資源。

305 Use Proxy

被請(qǐng)求的資源必須通過(guò)指定的代理才能被訪問(wèn)。Location域中將給出指定的代理所在的URI信息，接收者需要重復(fù)發(fā)送一個(gè)單獨(dú)的請(qǐng)求，通過(guò)這個(gè)代理才能訪問(wèn)相應(yīng)資源。只有原始服務(wù)器才能創(chuàng)建305響應(yīng)。許多HTTP客戶端（像是Mozilla和Internet Explorer）都沒(méi)有正確處理這種狀態(tài)代碼的響應(yīng)，主要是出于安全考慮。 注意：RFC 2068中沒(méi)有明確305響應(yīng)是為了重定向一個(gè)單獨(dú)的請(qǐng)求，而且只能被原始服務(wù)器建立。忽視這些限制可能導(dǎo)致嚴(yán)重的安全后果。

306 Switch Proxy

在最新版的規(guī)范中，306狀態(tài)碼已經(jīng)不再被使用。最初是指“后續(xù)請(qǐng)求應(yīng)使用指定的代理”。

307 Temporary Redirect

在這種情況下，請(qǐng)求應(yīng)該與另一個(gè)URI重復(fù)，但后續(xù)的請(qǐng)求應(yīng)仍使用原始的URI。 與302相反，當(dāng)重新發(fā)出原始請(qǐng)求時(shí)，不允許更改請(qǐng)求方法。 例如，應(yīng)該使用另一個(gè)POST請(qǐng)求來(lái)重復(fù)POST請(qǐng)求。

308 Permanent Redirect (RFC 7538)

請(qǐng)求和所有將來(lái)的請(qǐng)求應(yīng)該使用另一個(gè)URI重復(fù)。 307和308重復(fù)302和301的行為，但不允許HTTP方法更改。 例如，將表單提交給永久重定向的資源可能會(huì)順利進(jìn)行。

4xx 客戶端錯(cuò)誤

這類(lèi)的狀態(tài)碼代表了客戶端看起來(lái)可能發(fā)生了錯(cuò)誤，妨礙了服務(wù)器的處理。除非響應(yīng)的是一個(gè)HEAD請(qǐng)求，否則服務(wù)器就應(yīng)該返回一個(gè)解釋當(dāng)前錯(cuò)誤狀況的實(shí)體，以及這是臨時(shí)的還是永久性的狀況。這些狀態(tài)碼適用于任何請(qǐng)求方法。瀏覽器應(yīng)當(dāng)向用戶顯示任何包含在此類(lèi)錯(cuò)誤響應(yīng)中的實(shí)體內(nèi)容。[30]

如果錯(cuò)誤發(fā)生時(shí)客戶端正在傳送數(shù)據(jù)，那么使用TCP的服務(wù)器實(shí)現(xiàn)應(yīng)當(dāng)仔細(xì)確保在關(guān)閉客戶端與服務(wù)器之間的連接之前，客戶端已經(jīng)收到了包含錯(cuò)誤信息的數(shù)據(jù)包。如果客戶端在收到錯(cuò)誤信息后繼續(xù)向服務(wù)器發(fā)送數(shù)據(jù)，服務(wù)器的TCP棧將向客戶端發(fā)送一個(gè)重置數(shù)據(jù)包，以清除該客戶端所有還未識(shí)別的輸入緩沖，以免這些數(shù)據(jù)被服務(wù)器上的應(yīng)用程序讀取并干擾后者。

400 Bad Request

由于明顯的客戶端錯(cuò)誤（例如，格式錯(cuò)誤的請(qǐng)求語(yǔ)法，太大的大小，無(wú)效的請(qǐng)求消息或欺騙性路由請(qǐng)求），服務(wù)器不能或不會(huì)處理該請(qǐng)求。

401 Unauthorized（RFC 7235）

參見(jiàn)：HTTP基本認(rèn)證、HTTP摘要認(rèn)證 類(lèi)似于403 Forbidden，401語(yǔ)義即“未認(rèn)證”，即用戶沒(méi)有必要的憑據(jù)。該狀態(tài)碼表示當(dāng)前請(qǐng)求需要用戶驗(yàn)證。該響應(yīng)必須包含一個(gè)適用于被請(qǐng)求資源的WWW-Authenticate信息頭用以詢問(wèn)用戶信息。客戶端可以重復(fù)提交一個(gè)包含恰當(dāng)?shù)腁uthorization頭信息的請(qǐng)求。如果當(dāng)前請(qǐng)求已經(jīng)包含了Authorization證書(shū)，那么401響應(yīng)代表著服務(wù)器驗(yàn)證已經(jīng)拒絕了那些證書(shū)。如果401響應(yīng)包含了與前一個(gè)響應(yīng)相同的身份驗(yàn)證詢問(wèn)，且瀏覽器已經(jīng)至少嘗試了一次驗(yàn)證，那么瀏覽器應(yīng)當(dāng)向用戶展示響應(yīng)中包含的實(shí)體信息，因?yàn)檫@個(gè)實(shí)體信息中可能包含了相關(guān)診斷信息。 注意：當(dāng)網(wǎng)站（通常是網(wǎng)站域名）禁止IP地址時(shí)，有些網(wǎng)站狀態(tài)碼顯示的401，表示該特定地址被拒絕訪問(wèn)網(wǎng)站。

402 Payment Required

該狀態(tài)碼是為了將來(lái)可能的需求而預(yù)留的。該狀態(tài)碼最初的意圖可能被用作某種形式的數(shù)字現(xiàn)金或在線支付方案的一部分，但幾乎沒(méi)有哪家服務(wù)商使用，而且這個(gè)狀態(tài)碼通常不被使用。如果特定開(kāi)發(fā)人員已超過(guò)請(qǐng)求的每日限制，Google Developers API會(huì)使用此狀態(tài)碼。

403 Forbidden

主條目：HTTP 403 服務(wù)器已經(jīng)理解請(qǐng)求，但是拒絕執(zhí)行它。與401響應(yīng)不同的是，身份驗(yàn)證并不能提供任何幫助，而且這個(gè)請(qǐng)求也不應(yīng)該被重復(fù)提交。如果這不是一個(gè)HEAD請(qǐng)求，而且服務(wù)器希望能夠講清楚為何請(qǐng)求不能被執(zhí)行，那么就應(yīng)該在實(shí)體內(nèi)描述拒絕的原因。當(dāng)然服務(wù)器也可以返回一個(gè)404響應(yīng)，假如它不希望讓客戶端獲得任何信息。

404 Not Found

主條目：HTTP 404 請(qǐng)求失敗，請(qǐng)求所希望得到的資源未被在服務(wù)器上發(fā)現(xiàn)，但允許用戶的后續(xù)請(qǐng)求。[35]沒(méi)有信息能夠告訴用戶這個(gè)狀況到底是暫時(shí)的還是永久的。假如服務(wù)器知道情況的話，應(yīng)當(dāng)使用410狀態(tài)碼來(lái)告知舊資源因?yàn)槟承﹥?nèi)部的配置機(jī)制問(wèn)題，已經(jīng)永久的不可用，而且沒(méi)有任何可以跳轉(zhuǎn)的地址。404這個(gè)狀態(tài)碼被廣泛應(yīng)用于當(dāng)服務(wù)器不想揭示到底為何請(qǐng)求被拒絕或者沒(méi)有其他適合的響應(yīng)可用的情況下。

405 Method Not Allowed

請(qǐng)求行中指定的請(qǐng)求方法不能被用于請(qǐng)求相應(yīng)的資源。該響應(yīng)必須返回一個(gè)Allow頭信息用以表示出當(dāng)前資源能夠接受的請(qǐng)求方法的列表。例如，需要通過(guò)POST呈現(xiàn)數(shù)據(jù)的表單上的GET請(qǐng)求，或只讀資源上的PUT請(qǐng)求。 鑒于PUT，DELETE方法會(huì)對(duì)服務(wù)器上的資源進(jìn)行寫(xiě)操作，因而絕大部分的網(wǎng)頁(yè)服務(wù)器都不支持或者在默認(rèn)配置下不允許上述請(qǐng)求方法，對(duì)于此類(lèi)請(qǐng)求均會(huì)返回405錯(cuò)誤。

406 Not Acceptable

參見(jiàn)：內(nèi)容協(xié)商 請(qǐng)求的資源的內(nèi)容特性無(wú)法滿足請(qǐng)求頭中的條件，因而無(wú)法生成響應(yīng)實(shí)體，該請(qǐng)求不可接受。[36] 除非這是一個(gè)HEAD請(qǐng)求，否則該響應(yīng)就應(yīng)當(dāng)返回一個(gè)包含可以讓用戶或者瀏覽器從中選擇最合適的實(shí)體特性以及地址列表的實(shí)體。實(shí)體的格式由Content-Type頭中定義的媒體類(lèi)型決定。瀏覽器可以根據(jù)格式及自身能力自行作出最佳選擇。但是，規(guī)范中并沒(méi)有定義任何作出此類(lèi)自動(dòng)選擇的標(biāo)準(zhǔn)。

407 Proxy Authentication Required（RFC 2617）

與401響應(yīng)類(lèi)似，只不過(guò)客戶端必須在代理服務(wù)器上進(jìn)行身份驗(yàn)證。[37]代理服務(wù)器必須返回一個(gè)Proxy-Authenticate用以進(jìn)行身份詢問(wèn)。客戶端可以返回一個(gè)Proxy-Authorization信息頭用以驗(yàn)證。

408 Request Timeout

請(qǐng)求超時(shí)。根據(jù)HTTP規(guī)范，客戶端沒(méi)有在服務(wù)器預(yù)備等待的時(shí)間內(nèi)完成一個(gè)請(qǐng)求的發(fā)送，客戶端可以隨時(shí)再次提交這一請(qǐng)求而無(wú)需進(jìn)行任何更改。

409 Conflict

表示因?yàn)檎?qǐng)求存在沖突無(wú)法處理該請(qǐng)求，例如多個(gè)同步更新之間的編輯沖突。

410 Gone

表示所請(qǐng)求的資源不再可用，將不再可用。當(dāng)資源被有意地刪除并且資源應(yīng)被清除時(shí)，應(yīng)該使用這個(gè)。在收到410狀態(tài)碼后，用戶應(yīng)停止再次請(qǐng)求資源。但大多數(shù)服務(wù)端不會(huì)使用此狀態(tài)碼，而是直接使用404狀態(tài)碼。

411 Length Required

服務(wù)器拒絕在沒(méi)有定義Content-Length頭的情況下接受請(qǐng)求。在添加了表明請(qǐng)求消息體長(zhǎng)度的有效Content-Length頭之后，客戶端可以再次提交該請(qǐng)求。

412 Precondition Failed（RFC 7232）

服務(wù)器在驗(yàn)證在請(qǐng)求的頭字段中給出先決條件時(shí)，沒(méi)能滿足其中的一個(gè)或多個(gè)。這個(gè)狀態(tài)碼允許客戶端在獲取資源時(shí)在請(qǐng)求的元信息（請(qǐng)求頭字段數(shù)據(jù)）中設(shè)置先決條件，以此避免該請(qǐng)求方法被應(yīng)用到其希望的內(nèi)容以外的資源上。

413 Request Entity Too Large（RFC 7231）

前稱(chēng)“Request Entity Too Large”，表示服務(wù)器拒絕處理當(dāng)前請(qǐng)求，因?yàn)樵撜?qǐng)求提交的實(shí)體數(shù)據(jù)大小超過(guò)了服務(wù)器愿意或者能夠處理的范圍。此種情況下，服務(wù)器可以關(guān)閉連接以免客戶端繼續(xù)發(fā)送此請(qǐng)求。 如果這個(gè)狀況是臨時(shí)的，服務(wù)器應(yīng)當(dāng)返回一個(gè)Retry-After的響應(yīng)頭，以告知客戶端可以在多少時(shí)間以后重新嘗試。

414 Request-URI Too Long（RFC 7231）

前稱(chēng)“Request-URI Too Long”，表示請(qǐng)求的URI長(zhǎng)度超過(guò)了服務(wù)器能夠解釋的長(zhǎng)度，因此服務(wù)器拒絕對(duì)該請(qǐng)求提供服務(wù)。通常將太多數(shù)據(jù)的結(jié)果編碼為GET請(qǐng)求的查詢字符串，在這種情況下，應(yīng)將其轉(zhuǎn)換為POST請(qǐng)求。這比較少見(jiàn)，通常的情況包括： 本應(yīng)使用POST方法的表單提交變成了GET方法，導(dǎo)致查詢字符串過(guò)長(zhǎng)。 重定向URI“黑洞”，例如每次重定向把舊的URI作為新的URI的一部分，導(dǎo)致在若干次重定向后URI超長(zhǎng)。 客戶端正在嘗試?yán)媚承┓?wù)器中存在的安全漏洞攻擊服務(wù)器。這類(lèi)服務(wù)器使用固定長(zhǎng)度的緩沖讀取或操作請(qǐng)求的URI，當(dāng)GET后的參數(shù)超過(guò)某個(gè)數(shù)值后，可能會(huì)產(chǎn)生緩沖區(qū)溢出，導(dǎo)致任意代碼被執(zhí)行。沒(méi)有此類(lèi)漏洞的服務(wù)器，應(yīng)當(dāng)返回414狀態(tài)碼。

415 Unsupported Media Type

對(duì)于當(dāng)前請(qǐng)求的方法和所請(qǐng)求的資源，請(qǐng)求中提交的互聯(lián)網(wǎng)媒體類(lèi)型并不是服務(wù)器中所支持的格式，因此請(qǐng)求被拒絕。例如，客戶端將圖像上傳格式為svg，但服務(wù)器要求圖像使用上傳格式為jpg。

416 Requested Range Not Satisfiable（RFC 7233）

前稱(chēng)“Requested Range Not Satisfiable”。客戶端已經(jīng)要求文件的一部分（Byte serving），但服務(wù)器不能提供該部分。例如，如果客戶端要求文件的一部分超出文件尾端。

417 Expectation Failed

在請(qǐng)求頭Expect中指定的預(yù)期內(nèi)容無(wú)法被服務(wù)器滿足，或者這個(gè)服務(wù)器是一個(gè)代理服顯的證據(jù)證明在當(dāng)前路由的下一個(gè)節(jié)點(diǎn)上，Expect的內(nèi)容無(wú)法被滿足。

418 I’m a teapot（RFC 2324）

本操作碼是在1998年作為IETF的傳統(tǒng)愚人節(jié)笑話, 在RFC 2324超文本咖啡壺控制協(xié)議’中定義的，并不需要在真實(shí)的HTTP服務(wù)器中定義。當(dāng)一個(gè)控制茶壺的HTCPCP收到BREW或POST指令要求其煮咖啡時(shí)應(yīng)當(dāng)回傳此錯(cuò)誤。這個(gè)HTTP狀態(tài)碼在某些網(wǎng)站（包括Google.com）與項(xiàng)目（如Node.js、ASP.NET和Go語(yǔ)言）中用作彩蛋。

420 Enhance Your Caim

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

421 Misdirected Request （RFC 7540）

該請(qǐng)求針對(duì)的是無(wú)法產(chǎn)生響應(yīng)的服務(wù)器（例如因?yàn)檫B接重用）。

422 Unprocessable Entity（WebDAV；RFC 4918 ）

請(qǐng)求格式正確，但是由于含有語(yǔ)義錯(cuò)誤，無(wú)法響應(yīng)。

423 Locked（WebDAV；RFC 4918）

當(dāng)前資源被鎖定。

424 Failed Dependency（WebDAV；RFC 4918）

由于之前的某個(gè)請(qǐng)求發(fā)生的錯(cuò)誤，導(dǎo)致當(dāng)前請(qǐng)求失敗，例如PROPPATCH。

425 Unordered Collection

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

426 Upgrade Required（RFC 2817）

客戶端應(yīng)當(dāng)切換到TLS/1.0，并在HTTP/1.1 Upgrade header中給出。

428 Precondition Required (RFC 6585)

原服務(wù)器要求該請(qǐng)求滿足一定條件。這是為了防止“‘未更新’問(wèn)題，即客戶端讀取（GET）一個(gè)資源的狀態(tài)，更改它，并將它寫(xiě)（PUT）回服務(wù)器，但這期間第三方已經(jīng)在服務(wù)器上更改了該資源的狀態(tài)，因此導(dǎo)致了沖突?！?/p>

429 Too Many Requests （RFC 6585）

用戶在給定的時(shí)間內(nèi)發(fā)送了太多的請(qǐng)求。旨在用于網(wǎng)絡(luò)限速。

431 Request Header Fields Too Large （RFC 6585）

服務(wù)器不愿處理請(qǐng)求，因?yàn)橐粋€(gè)或多個(gè)頭字段過(guò)大。

444 No Response

Nginx上HTTP服務(wù)器擴(kuò)展。服務(wù)器不向客戶端返回任何信息，并關(guān)閉連接（有助于阻止惡意軟件）。

450 Blocked by Windows Parental Controls

這是一個(gè)由Windows家庭控制（Microsoft）HTTP阻止的450狀態(tài)代碼的示例，用于信息和測(cè)試。

451 Unavailable For Legal Reasons

該訪問(wèn)因法律的要求而被拒絕，由IETF在2015核準(zhǔn)后新增加。

494 Request Header Too Large

在錯(cuò)誤代碼431提出之前Nginx上使用的擴(kuò)展HTTP代碼。

5xx 服務(wù)器錯(cuò)誤

表示服務(wù)器無(wú)法完成明顯有效的請(qǐng)求。[56]這類(lèi)狀態(tài)碼代表了服務(wù)器在處理請(qǐng)求的過(guò)程中有錯(cuò)誤或者異常狀態(tài)發(fā)生，也有可能是服務(wù)器意識(shí)到以當(dāng)前的軟硬件資源無(wú)法完成對(duì)請(qǐng)求的處理。除非這是一個(gè)HEAD請(qǐng)求，否則服務(wù)器應(yīng)當(dāng)包含一個(gè)解釋當(dāng)前錯(cuò)誤狀態(tài)以及這個(gè)狀況是臨時(shí)的還是永久的解釋信息實(shí)體。瀏覽器應(yīng)當(dāng)向用戶展示任何在當(dāng)前響應(yīng)中被包含的實(shí)體。這些狀態(tài)碼適用于任何響應(yīng)方法。

500 Internal Server Error

通用錯(cuò)誤消息，服務(wù)器遇到了一個(gè)未曾預(yù)料的狀況，導(dǎo)致了它無(wú)法完成對(duì)請(qǐng)求的處理。沒(méi)有給出具體錯(cuò)誤信息。

501 Not Implemented

服務(wù)器不支持當(dāng)前請(qǐng)求所需要的某個(gè)功能。當(dāng)服務(wù)器無(wú)法識(shí)別請(qǐng)求的方法，并且無(wú)法支持其對(duì)任何資源的請(qǐng)求。（例如，網(wǎng)絡(luò)服務(wù)API的新功能）

502 Bad Gateway

作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，從上游服務(wù)器接收到無(wú)效的響應(yīng)。

503 Service Unavailable

由于臨時(shí)的服務(wù)器維護(hù)或者過(guò)載，服務(wù)器當(dāng)前無(wú)法處理請(qǐng)求。這個(gè)狀況是暫時(shí)的，并且將在一段時(shí)間以后恢復(fù)。如果能夠預(yù)計(jì)延遲時(shí)間，那么響應(yīng)中可以包含一個(gè)Retry-After頭用以標(biāo)明這個(gè)延遲時(shí)間。如果沒(méi)有給出這個(gè)Retry-After信息，那么客戶端應(yīng)當(dāng)以處理500響應(yīng)的方式處理它。

504 Gateway Timeout

作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，未能及時(shí)從上游服務(wù)器（URI標(biāo)識(shí)出的服務(wù)器，例如HTTP、FTP、LDAP）或者輔助服務(wù)器（例如DNS）收到響應(yīng)。 注意：某些代理服務(wù)器在DNS查詢超時(shí)時(shí)會(huì)返回400或者500錯(cuò)誤。

505 HTTP Version Not Supported

服務(wù)器不支持，或者拒絕支持在請(qǐng)求中使用的HTTP版本。[63]這暗示著服務(wù)器不能或不愿使用與客戶端相同的版本。響應(yīng)中應(yīng)當(dāng)包含一個(gè)描述了為何版本不被支持以及服務(wù)器支持哪些協(xié)議的實(shí)體。

506 Variant Also Negotiates（RFC 2295）

由《透明內(nèi)容協(xié)商協(xié)議》（RFC 2295）擴(kuò)展，代表服務(wù)器存在內(nèi)部配置錯(cuò)誤，被請(qǐng)求的協(xié)商變?cè)Y源被配置為在透明內(nèi)容協(xié)商中使用自己，因此在一個(gè)協(xié)商處理中不是一個(gè)合適的重點(diǎn)。

507 Insufficient Storage（WebDAV；RFC 4918）

服務(wù)器無(wú)法存儲(chǔ)完成請(qǐng)求所必須的內(nèi)容。這個(gè)狀況被認(rèn)為是臨時(shí)的。

508 Loop Detected （WebDAV；RFC 5842）

服務(wù)器在處理請(qǐng)求時(shí)陷入死循環(huán)。 （可代替 208狀態(tài)碼）

510 Not Extended（RFC 2774）

獲取資源所需要的策略并沒(méi)有被滿足。

511 Network Authentication Required （RFC 6585）

客戶端需要進(jìn)行身份驗(yàn)證才能獲得網(wǎng)絡(luò)訪問(wèn)權(quán)限，旨在限制用戶群訪問(wèn)特定網(wǎng)絡(luò)。（例如連接WiFi熱點(diǎn)時(shí)的強(qiáng)制網(wǎng)絡(luò)門(mén)戶）

柚子快報(bào)激活碼778899分享：Postman使用-基礎(chǔ)篇

http://yzkb.51969.com/

好文鏈接