随着 API 的日益普及，对易于使用的 API 客户端的需求也同样不断扩大。今天几乎所有东西都有 API，许多软件公司都提供 API 访问他们自己通过各自的 UI 提供的功能，允许消费者为特定或一般用例包装该功能。上周我被一位朋友介绍给 Buffer ，他通过他的公司 Zomalo 与许多社交媒体策略师合作，我注意到他们的 API，并且他们有几个 Ruby 宝石。一个 gem 包装了 Buffer 使用的对象，而另一个提供了用于授权的 Devise 集成。这些 gems 充其量也没有很好的记录，而前者未能提供一个有凝聚力的客户端，允许用户快速轻松地调用他们的端点并将 JSON 解析为 Ruby 哈希，这是我的主要用例，我觉得对于任何实现基于缓冲区的 Web 应用程序的人来说都是一个重要的问题。
因此，为 Buffer 创建灵活、易于使用的 Ruby gem 的想法诞生了。我在之前的一篇文章中写过关于 现代 API 的兴起 ，以及如何（也许应该）为消费者构建稳定的 API。在另一篇文章中，我写了关于将 技术集成到无缝解决方案中的 规则。将它们放在一起，我决定让我的 gem 成为一个公开可用的 API 客户端示例，它遵循我自己的规则，我将其命名为 Buffer Ruby 。
我创建此类客户端的灵感之一是 Octokit ，它包装了 Github API，这是另一个非常直接且设计良好的 API。用他们自己的话说，Octokit“将 Github API 包装在一个遵循 Ruby 约定并且几乎不需要 REST 知识的平面 API 客户端中。”目标很简单：让仅拥有 自述文件 的用户能够快速轻松地与 Buffer API 进行交互。客户应该是：
-
安全：即使收到错误或格式错误的数据，客户端也不应崩溃
-
稳定：测试（和测试自动化）应提供足够的覆盖范围以确保客户端始终正常运行
-
标准：作为自动化的一部分，您还应该知道新提交的代码中是否存在已知的不良代码味道、重复的功能以及可能的安全问题
-
兼容：我设计 Buffer Ruby 是为了确保它可以在 Ruby 1.9+ 上运行，以供那些仍然坚持使用 Ruby 1.9 的开发人员使用
-
信息性的：Buffer Ruby 实现了 Buffer 提供的每条错误消息，让用户清楚地了解失败的原因和原因
-
灵活：如果一个调用不需要授权令牌而另一个调用需要，则客户端应该能够在事后配置以设置或重置这些令牌
-
简单：只需一行即可安装 gem 及其所有依赖项，并且在自述文件中应该清楚地详细说明 入门
第 1-4 项是关于从技术角度使最佳客户端成为可能，这样代码更改不会对消费者或意外行为产生负面影响。他们确保代码遵循质量标准，并确保客户端与尽可能广泛的用户兼容。为了确保 gem 是安全的，我在 RSpec 中编写了测试覆盖率，这是一个强大而灵活的 Ruby 和 Ruby on Rails 单元测试框架。 RSpec 的一些主要优点包括复杂的方法存根、网络调用存根、实例变量操作、嵌套测试范围和种类繁多的匹配器。如果您是普通的 Ruby 和/或 Ruby on Rails 开发人员，我强烈建议您彻底学习 RSpec。为了证明这种稳定性，我需要覆盖客户端底层的大部分对象，这些对象被类似的功能分开，以便于维护和在 Buffer API 文档中查找。然后我将 repo 连接到两个用于开源项目的惊人的免费服务。
Travis CI 是一个自动化框架，它允许我在每次提交到存储库（包括我的开发分支）时运行我的 RSpec 测试，以确保我不会不小心合并损坏的代码。 Travis CI 还与 Code Climate 直接集成，这是一个出色的（而且还是免费的）框架，可以扫描您的代码是否存在不良代码味道（如重复代码、复杂方法等），并为您提供 GPA。当与 Travis CI 集成时，它还按文件提供代码覆盖率，这使我能够快速定位我应该针对其编写测试的代码。 Travis CI 还允许我针对多个版本的 Ruby 进行测试，在本例中为 Ruby 1.9.3 和 2.1.2。
项目 5-7 侧重于从消费者的角度尽可能提供最佳客户端，以降低使用准入门槛。通过提供有用的错误消息，如果出现问题，消费者无需深入研究 Buffer API 文档。通过提供具有清晰输入和输出的良好文档（以及原始 API 文档的链接），它允许利益相关者仅访问一个页面并在短短几分钟内了解他们使用客户端所需的一切。
有大量没有客户端（或没有开发良好的客户端）的 API 示例可供您练习，虽然我所做的在很多方面都是 Ruby 特有的，但这些概念可以应用于任何 API 的任何实现客户。我期待听到您所有的创造性努力，并一如既往地祝您黑客愉快！