在我们构建新的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结构对于整体的增长和伸缩是有利还是有害。