在我们构建新的 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 )关注我们。
评论