丰富了附录B中的Web API检查清单，给予了一些必要的解释与说明，方便大家快速学习。
另外，以下只是作者的建议，使用需结合实际情况。
- URI是否短小且容易输入
好的例子：http://api.example.com/search
坏的例子：http://api.example.com/service/api/search。
域名已经是api，在URI就没有必要重复一些毫无意义的单词。
- URI是否能让人一眼看懂
不要轻易使用缩写：http://api.example.com/sv/u
使用更地道的英语表达，比如搜索接口一般用search而不是find，可以多参照一些国外大厂的API。
- URI是否只有小写字母组成
HTTP协议指定了：URL中除了schema和hostname不区分大小写，其他部分均大小写敏感。
因此，URI应该使用小写，禁止大小写混写。
- URI是否容易修改
比如获取某个商品信息的URI应该长这样：http://api.example.com/v1/items/12346
从URI直观的即可知道获取56780商品的URI是这样：http://api.example.com/v1/items/56780。
开发者对URI的行为理解是自然的，不费心的。
- URI是否反映了服务端的架构
不要暴露服务端是哪种开发语言，下面是错误的例子：
http://api.example.com/cgi-bin/get_user.php?user=100
- URI规则是否统一
URI中的词汇和结构应该保持统一。
下面是一个错误的例子：
获取好友信息：http://api.example.com/friends?id=100
发送信息：http://api.example.com/friend/100/messages
首先，friends和friend的单复数形式不统一，你可以想象API使用者是如何被这种细小的差异坑了半天。
其次，一个通过get参数传参，一个通过URI路径传参，不够统一。
一个正确的例子：
获取好友信息：http://api.example.com/friends/100
发送信息：http://api.example.com/friends/100/messages
该例子遵循REST风格，下面讲解REST URI设计风格。
- 有没有使用合适的HTTP方法
作者强调REST风格。
HTTP方法表示"进行怎样的操作"，URI表示"资源"，HTTP和URI一起则表示"对什么资源做什么操作"。
GET：获取资源
获取ID=100的好友信息，
GET http://api.example.com/friends/100
POST：新增资源
添加一位好友，相当于新建一个好友关系：
POST http://api.example.com/friends
PUT：更新已有资源
更新ID=100的好友信息（例如：更新备注信息），
PUT http://api.example.com/friends/100
PATCH：更新部分资源
和PUT类似，只是强调更新资源的部分信息，不常用。
DELETE：删除资源
删除ID=100的好友信息：
DELETE http://api.example.com/friends/100
HEAD：获取资源的元信息
这个作者没有详细去说一个资源的元信息应该是什么样的。
感觉和自己设计的API不太一样吧？这就是REST风格，常见于国外各种大厂。
- URI里用到的单词所表达的意思是否和大部分API相同
有点重复，还是强调对于非英语母语的开发者，应该注意使用地道准确的单词。
比如，照片应该用photo而不是picture。
- URI里用到的名词是否采用了复数形式
因为URI表示资源的集合，所以作者是建议总是使用复数形式。
正确的例子：http://api.example.com/friends/100
错误的例子：http://api.example.com/friend/100
另外，因为REST风格强调URI是资源，所以不应该在URI里出现动词，因为动作是HTTP方法表达的。
错误的例子：http://api.example.com/get_friend?id=100
- URI里有没有空格符以及需要编码的字符
URL是会被urlencode编码的，所以不要在URI里使用空格（会被编码成+）、UTF-8字符、乱七八糟的符号等。
即不要影响URI的可读性。
- URI里的单词和单词之间有没有使用连接符
因为URL中的hostname不允许使用下划线，所以作者建议URI部分总是使用连字符-来连接多个单词。
- 分页的设计是否恰当
分页参数分2种风格，可以按情况使用：
第一种，表示第3页，每一页50条：
page=3&per_page=50
第二种：表示从100条开始的50条：
offset=100&limit=50
前者page从1开始增长，后者offset从0开始增长。
前者对用户来说自由度较低，缓存命中率较高。
后者对用户来说自由度较高，缓存命中率较低。
上述翻页风格称为"相对位置"，深度翻页性能差（可以自己扩展学习），如果数据集合有更新，则翻页时可能看到重复内容或者错过一些内容。
与之相对的是"绝对位置"，即指定last_id之前的N条数据，下次使用新的last_id继续获取。（个人理解瀑布流页面比较适合）
- 登录有没有使用OAuth2.0
很常见的认证规范，让用户通过大厂的账号系统登录，并授权给第三方获取用户信息的权限。
作者表达的意思是你如果对外提供API，应该提供OAuth2.0认证，这样第三方调用API时携带access_token，我们即可校验其是否有权使用API。
最后，作者描述了一下REST API的几个等级：
REST LEVEL0：使用HTTP
REST LEVEL1: 引入资源的概念
REST LEVEL2：引入HTTP动词（GET/POST/PUT/DELETE等）
REST LEVEL3：引入HATEOAS概念
本书是REST LEVEL2。
LEVEL3中的HATEOAS概念尚未普及，其思路是API返回的数据中应该包括下一步行为对应的URI是什么，客户端请求下一步的URI就可以得到进一步的数据。
比如文章列表的返回值：
{
"articles": [
{
"title": "good",
"uri": "https://api.example.com/v1/articles/12345",
"rel": "article/detail"
}
]
}
每一篇文章的uri告知客户端如何获取文章详情，属于一种高度灵活。
- 响应数据格式有没有使用JSON作为默认格式
越简单的东西越容易普及，JSON比XML简单的多，也满足需求，另外Javascript天然支持json。
客户端没有明确指定返回值格式的话，JSON应该作为默认的返回值格式。
- 是否支持通过查询参数来指定数据格式
如果服务端支持多种返回数据格式，那么客户端可以指定。
通过get参数：
https://api.example.com/v1/users?format=xml
通过扩展名：
https://api.example.com/v1/users.xml
通过HTTP头部：
GET /v1/users
Host: api.example.com
Accept: application/xml
作者建议首先使用HTTP头部，因为更符合HTTP协议规范；其次使用查询参数，避免使用扩展名。
- 是否支持不必要的JSONP
JSONP可以实现跨域HTTP调用，其原理是基于<script>加载一段服务端的javascript代码（自行扩展学习）。
API如果决定支持JSONP，可以在服务端判定客户端是否上传了callback参数，如果上传了就返回jsonp格式。
客户端为了区分不同的JSONP调用，需要为每个JSONP调用生成一个唯一的全局回调函数名，这一点Jquery可以帮我们实现。
出于正确性与安全性考虑，JSONP服务端返回时应该设置Content-Type: application/javascript而不是application/json，因为返回的是一段js函数调用代码。
作者提到，JSONP因为是作为一个script引入的，服务端可以通过2种方式返回错误信息：
1）在json响应体里放置error信息
2）在callback之外支持error_callback传参
- 响应数据的内容能不能从客户端指定
有时调用方只需要部分信息，比如：用户信息接口只希望获取用户ID，这样可以节约通讯量。
此类接口可以通过类似fields的get参数来指定返回哪些信息：
http://api.example.com/v1/users/12345?fields=name,age
另外也可以提前准备几种返回值的组合，称为响应群（response group），比如:
http://api.example.com/v1/users/12345?group=basic_info
其中，basic_info表示返回用户的基础信息，例如name和age。
- 响应数据中是否存在不必要的封装
作者出于rest风格原因，建议把错误码和错误信息放在http header里，而不是放在body里。
一个错误的例子：
HTTP/1.1 200 OK
{
"error_code": 500,
"error_msg": "参数错误",
"data": {}
}
作者认为HTTP返回200，但内容却表达了500失败，这样很奇怪，很不rest。
rest风格更建议用下面这种方式：
HTTP/1.1 500 参数错误
{
"data": {}
}
- 响应数据的结构有没有尽量做到扁平化
不要在JSON中增加无意义的多余层级，尽可能扁平化。
一个错误的例子：
{
"id": 12345,
"name": "hahaha",
"profile": {
"birthday": "0203",
"gender": "male",
"language": ["zh", "en"]
}
}
增加profile并没有带来什么价值，不如扁平化：
{
"id": 12345,
"name": "hahaha",
"birthday": "0203",
"gender": "male",
"language": ["zh", "en"]
}
不仅访问起来方便，而且传输的内容也少了。
- 响应数据有没有用对象来描述，而不是用数组
作者建议JSON返回值总是使用{}作为返回值的最外层，而不要直接返回数组[]。
正确的例子：
{
"articles": [
{"id": 1},
{"id": 2}
...
]
}
错误的例子：
[
{"id": 1},
{"id", 2}
]
这样做有2个次要的理由：
1，因为从字面看，articles能直接表达数据的含义
2，客户端在处理JSON应答时，可以统一将最外层作为对象去解析，不需要为数组做适配。
3，有一些安全性考虑，后面会提到。
- 响应数据的名称所选用的单词的意思是否和大部分API相同
对非英语母语的人，多模仿大厂使用的常见单词。
- 响应数据的名称有没有用尽可能少的单词来描述
关于用户注册时间字段，
错误的例子：userRegistraionDataTime
这个单词太长了，很容易打错，也不容易记忆。
正确的例子：registeredAt
- 响应数据的名称由多个单词连接而成时，连接方法在整个API里是否一致
有几种连接单词的方法：
1，user_id：蛇形法
2，user-id：脊柱法
3，userId：驼峰法
在JSON和Javascript中，都是建议使用驼峰法的，但是保持风格一致是最重要的。
- 响应数据的名称有没有使用奇怪的缩写形式
尽量避免奇怪的缩写，比如timezone写成tz。
如果出于数据量大小的考虑而采用缩写，属于特殊情况。
- 响应数据的名称的单复数形式是否和数据内容相一致
只为数组采用复数，比如friends。
其他情况使用单数。
一致的命名风格，API使用者会顺其自然，养成习惯。
- 出错时响应数据中是否包含有助于客户端剖析原因的信息
出错时，响应信息应该包含2部分：
1，错误码
2，错误原因
作者建议使用http header返回错误码，每种错误码的含义如下：
1xx：消息
2xx：成功
3xx：重定向
4xx：客户端原因引起的错误
5xx：服务端原因引起的错误
而不是在JSON中设置一个error_code字段，因为http code本身就是这个意思。
当http code为4xx或者5xx时，需要进一步告知客户端错误原因，这时候有2种做法：
1，在http header里自定义一些头部信息，保存错误原因，例如：
X-ERROR-MESSAGE: params error
2，在body中返回JSON格式的错误信息：
{
"errors": [
{
"message": "参数fields错误"
},
{
"message": "参数last_id错误"
}
]
}
作者建议采用第2种方式，因为可以描述多个错误原因，并且很多大厂都是这么做的。
- 出错时有没有返回HTML数据
当服务端发生错误时，很多web框架会打印一个html错误信息页面。
对于API来说，当发生错误时也应该返回一个合法的JSON结构，因为客户端假设服务端返回JSON，返回HTML可能导致异常。
- 有没有返回合适的状态码
这一条规则有点重复，主要是指返回适当的http code。
- 服务器端在维护时有没有返回503状态码
当服务器需要停机维护时，按照Google爬虫的建议，应该返回503错误码，并且在header中告知维护的结束时间：
503 Service Temporarily Unavailable
Retry-After: Mon, 2 Dec 2013 03:00:00 GMT
这遵循HTTP1.1规范，客户端需要实现逻辑去识别这个情况，但是至少google爬虫会去理解这些信息。
- 有没有返回合适的媒体类型
有的HTTP客户端会校验应答中的Content-Type字段，因此服务端如果返回的是JSON，那么就应该返回Content-Type: application/json而不是Content-Type: text/html，这样避免一些严格的客户端出现解析失败。
- 必要时能不能支持CORS
浏览器有同源策略，禁止跨域Ajax请求。
API可以支持CORS跨域资源共享，比如http://www.example.com请求http://api.example.com的API时应该携带请求的来源：
Origin: http://www.example.com
服务端只允许某些来源的跨域调用，如果Origin合法就在返回中携带：
Access-Control-Allow-Origin: http://www.example.com
或者
Access-Control-Allow-Origin: *
浏览器看到这样的应答，就会把ajax请求正常执行完成，否则会报告ajax调用失败。
对于一些特殊场景，浏览器会采用"事先请求"的方式，先通过一个OPTION方法调用到对应的接口来试探服务端是否返回Access-Control-Allow-Origin，如果没有返回则不发起真正的数据请求。
CORS客户端默认不会传输cookie，我们在发起ajax前设置XHTTPRequest.withCredentials=true，并且服务端必须返回header：Access-Control-Allow-Credentials: true，否则这次ajax调用将报告失败。
- 有没有返回Cache-Control、ETag、Last-Modified、Vary等首部以便客户端采用合适的缓存策略
缓存模型分2种：
1，过期模型：Expires、Cache-Control
2，验证模型：Last-Modified、ETag
过期模型是指，浏览器在过期之间直接使用本地缓存文件，下面是一个例子：
Expires: Fri, 01 Jan 2016 00:00:00 GMT
Cache-Control: max-age=3600
Cache-Control是HTTP1.1协议出现的，Expires是HTTP1.0，前者优先级更高。
并且HTTP1.1协议也规定，缓存时间不应超过1年，但实际上客户端可能没有遵循这个约束。
验证模型是指，客户端照常发起请求，但在header中携带附加条件，服务器根据附加条件判断若数据没有修改则返回304，客户端直接使用本地缓存即可，否则返回200并携带内容。
下面是个例子，
请求：
GET /v1/users/12345
If-Modified-Since: Tue, 01 Jul 2014 00:00:00 GMT
If-None-Match: "ff39b31e285573ee373af0d492aca581"
应答：
HTTP/1.1 304 Not Modified
Last-Modified: Tue, 01 Jul 2014 00:00:00 GMT
ETag: "ff39b31e285573ee373af0d492aca581"
需要注意ETag分为强验证和弱验证：
强验证是指资源的真实内容完全不能变，弱验证是指逻辑上资源没有改变即可。
- 不想缓存的数据有没有添加Cache-Control: no-cache首部信息
如果不希望被客户端缓存，可以指定Cache-Control: no-cache。
如果你的API前面存在反向代理缓存，可以额外声明Cache-Control: no-store，这样代理服务器也不会缓存数据了。
客户端可能多次请求同一个API，但是请求的http header不同，导致返回的内容结构不同，比如：
客户端携带 Accept: application/json，则服务端返回的是JSON。
客户端携带 Accept: application/xml，则服务端返回的是XML。
如果反向代理根据URI缓存，则会导致无法根据客户端的要求返回正确格式，此时我们API应该在返回值里携带Vary: Accept，这样缓存服务器会为不同的Accept分别缓存。
- 有没有对API进行版本管理
一般API会不断的迭代功能，有时会出现无法向下兼容的情况。
通常老客户端会依旧使用老版本的API，新客户端使用新版本的API，并在合适的时机完全下线掉老版本的API。
- API版本的命名有没有遵循语义化版本控制规范
作者介绍了语义化版本控制，通常版本号是a.b.c这样的，分别表示主版本号，次版本号，补丁版本号。
1，如果软件API没有变更，只是修复服务端BUG，那么就增加补丁版本号
2，对软件API实施了向下兼容的变更，增加次版本号
3，对软件API实施了不向下兼容的变更时，增加主版本号
- 有没有在URI里嵌入主版本编号，并且能够让人一目了然
对于Web API来说，作者建议在URI中嵌入主版本号即可，例如：
http://api.example.com/v1/users
整体原则是，尽量保持向下兼容，这样URI不会改变，老用户不需要迁移。
还有一个问题是，如果不带版本号访问应该套用哪个版本的接口？谷歌的做法是使用最老版本，这样就不会影响那些老用户了。
- 有没有考虑API终止提供时的相关事项
停止API时应该让API返回410错误码，它代表接口不再对外公开。
如果客户端是公司的产品，则可以强制客户端升级，避免停止API导致用户无法使用。
- 有没有在文档里明确注明API的最低提供期限
错误的例子：
该API 2018-06-01下线，请注意迁移。
正确的例子：
该API将继续维护12个月，请您尽快迁移。
错误的例子把期限说的太死了，而正确的例子则留了余地（比如再维护额外的12个月），使用者的感受会好很多。
- 有没有使用HTTPS来提供API
HTTP是明文传输，可以被任意劫持。
HTTPS采用SSL通讯，保障数据安全。但是HTTPS要求客户端严格验证证书的真伪，否则中间人可以伪造证书实施攻击。
另外，作者强调HTTPS会导致请求变慢，但相比安全性仍然是值得做的。
- 有没有认真执行JSON转义
一个这样的JSON，如果按照Content-Type: text/html被浏览器解析，其中的js就会被执行：
{"username": "<script>alert(1)</script>"}
好在大多数JSON库默认会在编码时会进行适当的转义，因此最终得不到执行：
{"username":"<script>alert(1)<\/script>"}
所以API应该返回完整转义过的JSON串，为了稳妥也应该设置Content-Type: application/json，避免浏览器将JSON当做html解析，导致攻击者得以实施XSS攻击。
- 能不能识别X-Request-With首部，让浏览器无法通过SCRIPT元素读取JSON数据
假设https://api.example.com/v1/users/me是获取当前登录用户信息的接口。
攻击者在自己的网站通过<script src="https://api.example.com/v1/users/me" language="vbscript"></script>可以实施攻击。
因为接口返回的是JSON，而加载时指定了vb语言肯定是无法解析成功的，因此攻击者通过设置window.onerror = function(err) {}即可被浏览器回调，从而从错误信息中获取到用户信息。
解决这个问题的方法是禁止通过script标签调用API，判定方法就是服务端判断请求中是否有Header X-Requested-With，因为Ajax请求默认会携带这个header而script不会。
- 通过浏览器访问的API有没有使用XSRF token
XSRF称为跨站点请求伪造。
攻击者在自己的网站做一个form表单，提交地址写为目标网站的表单提交地址。当受害者访问攻击者网站时，攻击者通过javascript自动提交form表单（form.submit），即可完成向目标网站的提交（想象这是一个转账表单）。
form表单提交不受同源策略（跨域）影响，因此可以达成上述攻击手段。
解决方法就是在表单里生成一次性的CSRF token放在隐藏字段中，并把token种植在用户cookie中，在用户提交表单到API时可以检查表单token和cookie中的token一致，则允许提交。
- API在接收参数时有没有仔细检查非法的参数（负数等）
作者以减少用户积分的API为例，如果传入一个负数积分，会导致减法变成加法，导致用户积分越来越多。
所以API需要严格校验参数是否合法。
- 有没有做到即使请求重复发送，数据也不会多次更新
作者其实就是想表达幂等性，举了一个支付系统的例子，就不详细描述了。
- 有没有在响应消息里添加各种增强安全性的首部
有很多header是作者建议总是加在API响应头里的，可以给浏览器很多建议，提升安全等级，就不一一描述了。
比较重要的一点是set-cookie时的安全问题：
1）Secure属性：表示cookie只能在访问https链接时才能被发送给服务端，这样可以彻底避免cookie被攻击者在网络中嗅探到。
2）HttpOnly属性：cookie仅能供HTTP调用时使用，而不允许javascript直接获取cookie，这样可以避免网站出现XSS漏洞的时候，攻击者通过JS代码把用户的会话cookie盗走。
- 有没有实施访问限速
限速是为了保护API服务，避免超过负载。
限速一般是针对每个用户的，限速的单位是多少分钟内最多访问多少次。
从实际存储上可以采用Redis，key的数量大概是"API的数量 * 用户数量"。
API超出限速应该返回429 Too Many Requests的http code，最好还能给出Retry-After告知多久后可以继续使用。
- 对预想的用例来说限速的次数有没有设置得过少
一般来说，应该为开放的API开发一套dashboard管理后台，从而可以灵活的为不同的用户设置不同的限速值，以及查看实时速率以及剩余调用次数等信息。