Web API核查表：设计、测试、发布API时需思考的43件事
当设计、测试或发布一个新的Web API时，你是在一个原有的复杂系统上构建新的系统。那么至少，你也要建立在HTTP上，而HTTP则是基于TCP/IP创建的、TCP/IP建立在一系列的管道上。当然，你也需要考虑Web服务器、应用程序框架或者是API框架。
API从设计到测试以至最终的发布需要经历一个漫长的过程，本文将主要探讨Web API从设计到最终发布，开发者可能忽略或者应该注意的东西。
HTTP篇
HTTP 1.1规范RFC2616是一个非常大的文档，下面我们节选了一些可能会对API产生影响的内容分享给大家：
1.Idempotent方法：GET、HEAD、PUT、DELETE、OPTIONS以及TRACE都属于idempotent操作；也就是说，“the side-effects of N > 0 identical requests is the same as for a single request.” （RFC2616 §9.1.2）
2．验证：用户访问API需要进行识别和验证，HTTP所提供的Authorization头文件就是出于此目的（RFC2616 §14.8）。RFC2617则指定了具体的验证计划，包括了最常见的HTTP基本验证。
3.201 Created：使用“201 Created”响应代码表示请求成功，并且创建了一个新资源。201响应可以包含本地头文件中的新资源URI。（RFC2616 §10.2.2）
4.202 Accepted：使用“202 Accepted”响应代码表示该请求是有效的，将会被处理，但还未完成。一般情况下是用在服务器后台队列可能出现的地方。（RFC2616 §10.2.3）
5.4XX和5XX状态代码：4XX状态代码与5XX状态代码有一个非常重要的区别：4XX代码旨在表明客户端错误，而5XX则是表明服务端错误。（RFC2616 §6.1.1）
6.410 Gone：“410 Gone”响应代码是一个很少使用的响应式代码，其主要是通知客户端资源出现在URL中，但实际上并没有。这个用在API里可以指明被删除、存档或过期的项目。（RFC2616 §10.4.11）
7.Expect:：100-continue：如果API客户端打算发送一个大型的实体请求，像POST、PUT或PATCH，它可以发送“Expect: 100-continue”到HTTP头文件里，在发送实体之前等待“100 continue”响应。这就允许API在返回错误响应信息之前，可以验证那些合理的请求（例如401或者403）。使用它可以提高API的响应能力以及在某些情景下减少宽带。（RFC2616 §8.2.3）
8.保持连接畅通：与API服务器保持连接，对于多API请求是个非常大的性能提升。如果配置正确，每个Web服务器应该支持keep-alive连接。
9.HTTP压缩：HTTP压缩可以同时用于响应体（Accept-Encoding: gzip）和请求体（Content-Encoding: gzip），用来提升HTTP API的网络性能。
10.HTTP缓存：在API响应时提供一个Cache-Control头文件。（RFC2616 §14.9）
11.缓存验证：如果你有缓存API，那么在响应时，你应该提供Last-Modified或Etag头文件，然后支持IF-Modified-Since或者If-None-Match请求头文件用于有条件的请求。这将允许客户端检查它们的缓存副本是否仍然有效，并且当没有请求时，阻止一个完整的资源下载。如果实现得当，那么条件请求要比普通请求更有效。（RFC2616 §13.3）
12.条件修改：ETag头文件也可以用于条件修改资源。（RFC2616 §14.24）
13.绝对重定向：这是一个鲜为人知的HTTP/1.1要求，重定向（如。201、301、302、303、307响应代码）应该包含一个绝对URI本地响应头文件。许多客户端在本地支持相对URI，但是如果你想让API兼容更多客户端，你应该在重定向时使用绝对URI。（RFC2616 §14.30）
14.链接响应头文件：在RESTful API中，经常需要提供转向其他资源的链接，甚至响应的内容类型无法提供一种自然方式链接（例如，PDF或图像）。RFC5988在响应头文件中指定了一个链接提供方法。
15.规范URL：对于多资源URL，RFC6596定义了统一的方法来规范网址链接。
16.块传输编码：如果响应内容太大，传输编码：分块（Chunked）是一种很好的流响应到客户端方式，它将会减少服务器和中间服务器的内存使用需求（尤其是对实现HTTP压缩），并且提供更快的首字节响应。
17.块传输编码里的错误处理：在实现块传输编码之前，弄清如何处理发生在中间请求时产生的错误是非常重要的。一旦对响应进行流处理，就无法改变HTTP的状态代码。
18. X-HTTP-Method-Override：有些HTTP客户端不支持任何GET和POST，但你可以通过POST开通其他HTTP方法，使用约定成俗的标准X-HTTP-Method-Overrider头文件去定义“真正”的HTTP方法。
19.URL长度：如果API支持复杂或任意的过滤项作为GET参数，那么记住，无论是客户端还是服务器端都可能会因为超过2000字节的URL长度带来兼容性问题。
API设计篇
20.无状态：没有人希望API能够存储状态，即使是在你的应用程序服务器端。保持应用程序服务器状态自由，可以做到很轻易和很轻松地扩展。
21.内容协商：让你的资源支持多种表现方式，你可以使用内容协商（content negotiation，例如Accept头文件），或者使用不同的URL（例如……?format=json），或者可以让你的内容协商重定向到具体的格式。
22.URI模板：URI模板是一个定义良好的机制，用来提供URI组合能力到客户端，或者定义URL访问终端用户模式。
23.Design for Intent：不要仅通过API来暴露内部业务对象，设计API语义意味着要与用户案例相匹配。更好地介绍，你可以阅读Darrel Miller写的API Craft。
24.版本：理论上讲，一个设计良好的API是无需创建兼容的。而对于实用主义者，它们会把版本放入到API的URL中（例如：a/v1/path），所以，除非是处在一个安全的网络状态下，否则API可能不会按照预期那样工作。
25.授权：记住，当设计API时，并不是所有的用户都可以访问里面的任何对象。
26.批量操作：发送较少的请求来获取或修改更多的数据，最好的方法就是在你的API里使用批量操作。
27.标记页数：API中使用分页服务主要有两大目的：一个是减少不必要的数据传送到客户端；一个是减少应用服务器端不必要的操作。
28.统一的字符编码：在设计和测试API时，Web服务需要支持更多的英文字符。如果你在URL中把Unicode字节作为自然键使用，它将会非常有趣（例如：/users/jimbob/ becomes /users/싸이/）。
29.错误日志：在设计API时，创建错误日志也是非常重要的。实践时最好创建两种日志记录，一个是服务器端，一个是客户端。
内容篇
30.内容类型：关于内容类型（Content Type）可以写整本书，就个人而言，我比较喜欢重用他人开发的内容类型，像Atom、Collection+JSON、JSON HAL或者XHTML。定义一套属于自己的内容类型会比你期望的更好。
31.HATEOAS：超媒体作为应用程序状态引擎是一个REST约束，简单点说就是你的内容应该通知客户端下面要做的事情，可以通过链接或表单来通知。
32.日期/时间：当你在API里提供日期/时间值时，应该使用一种格式，包括时区信息。RFC3339是ISO8601的一个子集，是最简单的日期时间格式。
安全篇
33.SSL：无论你的API是否支持HTTP或HTTPS，你都应该考虑HTTPS这种访问方式，它的增长趋势日益明显。
34.跨站请求伪造（CSRF）：如果使用API的交互式用户与普通用户都使用相同的验证，那么你的API很有可能会遭受CSRF攻击。
35.Throttling：如果一个API用户的请求数超过了规定，那么你应该提供一个带Retry-After header的503响应。
36.婉转的拒绝服务：Throttling可以阻止你用最简单的方式进行攻击，但这里还有其他更机智的攻击方式。例如Slowloris、Billion laughs、ReDoS，它们都不会占用太多资源，但是它们可以让你的API在瞬间耗尽所有资源。
客户端
无论你是否给用户提供测试代码或者是SDK开发包，都应该给他们提供一个客户端，并且遵循下面这几个步骤：
37.保持连接畅通：一些HTTP客户端需要做一些额外的工作来保持连接持久，持久的连接对感知API性能有着非常重要的影响。
38.授权之前的401：HTTP的另一个怪癖是，它们会在解决一个授权问题之前发出“401 Unauthorized”响应。这样就会延长API的请求时间。
39.Expect: 100-continue：至少有一个API客户端默认使用“Expect: 100-continue”，如果它没有接受“100 Continue”响应，在3秒的超时后会继续发送请求。如果API不支持“100 Continue”，或许会产生另一个性能缺陷，导致客户端禁用。
其它
40.文档：编写API文档是令人厌烦的，但是手写的API文档通常是最好的。编写时一定要包含这些内容：一些可运行的代码或者curl命令行，方便查阅。你也可以参考一些文档工具，例如：apiary.io、Mashery I/O Docs、Swagger。
41.设计与客户：不要在真空中设计API，要与客户打交道或者一起来设计API，参考用户用例。
42.反馈：在设计API时，应提供一个通道供用户进行反馈，
43.自动化测试：API测试是最简单的事情。它最好是自动化的，毕竟，需要好好利用它。
上面提供的这份列表有趣吗？对你是否有帮助呢？欢迎与我们一起讨论。