移动互联网盛行之前， RESTful API 就已经存在很久了，只不过恰巧移动桌面的的兴起让 RESTful API 变成了几乎任何需要联网设备的标配，它的普及也正好证明了它的重要性程度是和它的普及程度是一样的。虽然没有专门的厂商来定义 RESTful API 的标准，但是得意于大平台的垄断和其 API 使用范围的广泛性，大平台出品的开放式 API 几乎就可以成为一种标准，所以想要把你的 API 设计的更标准一点，参考一下主流开放平台的 API 即可，那些可参考的平台包括但不限于：twitter、Facebook、github、Yahoo、Google 等。
不论提供什么内容或服务的 API 从其诞生起一般要经历：定义设计、测试、上线、升级、维护等几个阶段，而 API 作为一种消费品不得不需要进行非常清晰的定义和描述才能真正投入实际生产使用，这就需要 API的定义 层级清晰，分组合理，文档美观，测试方便，升级容易。而 RESTFul 经过移动互联网的洗礼已经衍生出了很多解决方案来达到上述目的，甚至有的公司基于此已经成功做成了一桩大生意悄悄地发财，比如卖身 Oracle 的 apiary.io。
标准
虽然大厂的 API 可以参考成为一种标准，但是每次设计 API 都去翻翻大厂的文档显得真有点太逊了点，OpenAPI 和 swagger-ui 提供了关于 API 定义的标准，前者是 API 设计的一些规约，后者是基于此规约实现的自动化 API 文档和测试工具。有了这两者，你再也不会为了把 API 定义的更标准更通用而去和消费 API 的 开发者讨价还价了。
除了 swagger 其他一些 API 工具厂商也会提供一些轮子做 API 设计和文档的工具，比如 apiary 有 https://github.com/apiaryio/api-blueprint ，api-blueprint 定义了一种描述 API 的语言，这种语言更高阶，更合适开发者抒写和定义，这种语言也称之为领域驱动语言，是用来专门描述特定领域内容的高阶语言。api-blueprint 会把描述的 API 自动转换更有利于开发者的形式，类似 swagger-ui 那样。
文档
swagger-ui 在遵循 OAI 的同时其自身就是非常美观的 API 文档工具，swagger 支持的是 YML格式的描述，而 api-blueprint 是 markdown 格式，相比 swagger 更容易抒写。
api-blueprint 只提供了对 API 的描述，要根据它的描述输出好看的文档还需要借助支持这种语言的工具，在 api-blueprint 的官方提供了一些工具可以很好的完成文档的解析和渲染。
更多选择可以看 https://apiblueprint.org/tools.html#
测试
API 的测试是和 API 的定义密不可分的，拥有好的 API 定义是可以让 API 测试事半功倍的，一般的 API 设计工具都都会提供简单的 API 测试，也有专门的服务只提供相应的 API 测试服务比如 https://runscope.com/ ，API 测试也有不少开源的解决方案，比如网易的 https://github.com/NEYouFan/nei-toolkit ，这儿工具就集 API 定义、mock、测试与一体，wecatch 也自己实现过一个 API 测试工具 https://github.com/wecatch/turbo-api-test ，使用 yml 描述，利用 Python 的 unittest 自动生成测试套件并且汇报测试结果，我们已经在生产环境使用了，很轻便。
监控
监控可以理解为对生产环境 API 持续不断的测试并汇报健康状态，所以监控又是和测试密不可分的，不过不同于测试，对生成环境测试就需要注意不同 HTTP method 对产生的副作用，尤其是 POST 这种非幂等方法要非常谨慎使用，而当初 wecatch 造 turbo-api-test 一方面是为了测试，另一方面也是为了可以配合 zabbix 对生产环境的 API 健康状态进行监控和报警。
选择合适的一套工具
任何时候当你开始新的服务准备好开始新的 API 之前一定要根据自己的需要选择一整套完整的方案，从定义、文档、测试、监控都要面面俱到，并让团队所有人都遵循这一套规范，如此才能在 API 的整个生命周期之内无论团队成员如何变化，或者业务如何变化都能游刃有余解决 API 的一切问题。
