在我們構建新的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結構對于整體的增長和伸縮是有利還是有害。