玩转 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 热点时的强制网络门户）。