在我们构建新的 API 时，人们通常会在未来的不可知和对棘手问题的预优化之间感到迷茫。Dropbox 也不例外。构建 API 时，Dropbox 开发人员必须考虑到作为一家公司可能会出现的快速增长，同时也需要认识到，他们对 API 做出的任何变更，随着时间的推移总会被一部分 API 消费者认为是在倒退。那么他们最终是怎么解决这些问题的？答案是三思而后行。
Leah Culver 之前曾是 Dropbox 的一名开发人员，他去年发表了一篇博文，文中详细阐述了Dropbox 针对自身的API，从V1 版本到V2 版本的艰难升级过程。他们的第一个重大决定是，是否让现有的API 适配日益增长的消费者需求，因为他们扩展了Dropbox Pro 和核心功能。他们的决定主要围绕着与API 消费者的“共生关系”展开，Culver 将其描述为应对API 增长的秘密武器。他们面临两种需求，一个是以一种灵活的方式与其他公司应用集成，一个是不造成混乱，最终前者战胜了后者，连通性比之前的任何时刻都要来得重要。一项最新的Google调查显示，有四分之一的用户通过搜索引擎发现应用程序，根据 Statista 的报告显示，大约 2 到 3 百万个应用程序在安卓和苹果应用商店可供下载，对于这些应用程序来说，搜索可见性是非常重要的。越来越多的用户不愿意因为要使用相关功能而安装多个应用程序，而错过扩展 Dropbox API 的机会意味着与第三方应用程序集成度的下降，最终导致 Dropbox 用户的减少
然而，在创建 Dropbox API 的 V2 时，Dropbox 有关闭的趋势。Dropbox 创建了自定义的 JSON，而不是使用 REST 范式、GraphQL 或者套接字服务，这样很大程度上偏离了 REST 或 HTTP 的准则。不使用通用的 HTTP 状态码，Dropbox 转而针对所有的错误使用 409 错误码，并在消息体里附带了自定义的错误消息。Dropbox 的 API 处理层是一个 HTTP POST 方法。不需要使用请求消息的 URL 或消息头，Dropbox 接收一个 JSON 消息体作为输入，然后返回一个 JSON 消息体，不管执行的 API 操作是检索还是修改状态。
在伸缩性方面，Dropbox 的方式有几处优点和缺点。一方面，Dropbox 不受 REST 的死板、僵化天性的限制，这类限制不适用于所有的数据使用案例，所以常常让人完全误解。Steve Klabnik，RUST/RUBY 贡献者，同时也是 Rust for Rubyists 的作者，他声称，99.99% 的RESTful API 没有完全符合Roy Fielding 的REST 思想。这一论点打破了过往认为RESTful 规范可以让Dropbox 的API 很容易适配未来的应用场景的论调，因为他们不符合任何一套模型。然而，对应于他们所获得的灵活性，他们也失去了结构性和大多数开发人员的易理解性。
HTTP 状态码是一个通用标准，负责与 Dropbox API 集成的开发人员会很容易理解和使用，响应报文里面的自定义状态码不仅仅需要额外的字符串处理程序，而且也难以从编程角度理解不同的错误状态。在提供强大的 API 开发可能性的同时，混合使用 GET 和 POST 原语，分不清来自客户端的调用哪些是改变对象状态的操作，哪些是存粹的查询操作，这种集成方案具有潜在的风险。大部分自定义 API 架构要求掌握大量有关 Dropbox API 的领域知识，而不仅仅是把它当成一个简单的 API 看待。Dropbox 的开发人员 F. Metsys 写了一篇博文，在文章中他描述了Dropbox 的方式：“我们伺机选择了HTTP 的优点，而不会将自己绑定在它上面。”这意味着Dropbox 的API 可以提供其他API 无法提供的特性和数据可见性，或者也可能意味着一种令人困惑且紧凑的集成过程。只有时间可以告诉我们，Dropbox API 的ad hoc 结构对于整体的增长和伸缩是有利还是有害。
原文地址： Evolving APIs for Scale with Dropbox
感谢薛命灯对本文的审校。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。
评论