英文原文：Evolving APIs for Scale with Dropbox
在我们构建新的 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 结构对于整体的增长和伸缩是有利还是有害。