スケール性のために進化したDropbox API

新たなAPIを開発しようとする時、将来性の保証と事前最適化の板挟みになって行き詰まるのはよくあることだ。Dropboxも例外ではない。API開発時の彼らは、企業としての急速な成長を考慮する必要があることは当然ながら、将来的なAPIの変更が常に、少なくとも一部のユーザには否定的な認識をされることを理解していた。彼らの最終的な結論は何か？大切なのは熟慮を重ねることだ。

昨年公開されたブログ記事に、DropboxのデベロッパアドボケートだったLeah Culver氏が、V1からV2への移行時にDropboxが経験した苦労について詳細に説明している。最初の大きな決断は、拡大するユーザニーズに対応するために既存のAPIを変更してDropbox ProとDropboxのコア機能を拡張するべきか、というものだった。同社において意思決定の根幹をなすのはユーザとの“共存関係”だ。Culver氏はこれについて、適切なAPI拡張を実現するための秘訣である、と説明している。さまざまな企業のアプリケーションと柔軟に統合可能であることの必要性が、互換性を破棄して得られるメリットを上回ることに疑問の余地はない。複数のアプリケーション間の接続性は今日、前例を見ないほど重要なものになっているのだ。Googleが先日実施した調査では、アプリユーザの4人に1人が、検索を利用してアプリケーションを見つけていることが明らかになっている。しかしStatistaによれば、AndroidやAppleのアプリストアでダウンロード可能なアプリケーションの数は200から300万にも達している。これらのアプリストアを検索して、アプリを見つけられるようにすることは非常に重要だ。今日のユーザは、関連する機能のために複数のアプリを使用することを極端に嫌がるようになっている。DropboxがAPI拡張のチャンスを逸することは、サードパーティアプリケーションとの統合の機会を失うことでもあり、最終的にはDropboxユーザを失うことにもつながる。

Dropbox API V2を開発するにあたって、しかしながらDropboxは、明らかにトレンドを外れる決断をした。RESTあるいはGraphQL、さらにはソケットサーバといったパラダイムも利用せずに、JSON入力とJSON出力を備えた独自のAPIを開発して、RESTあるいはHTTPのガイドラインさえもほぼ無視したのだ。共通HTTPステータスコードを利用せず、すべてのエラーに409コードを使用し、独自のエラーメッセージをレスポンス本文に格納する方法を採用した。API処理層にはHTTP POSTを使用した。リクエストのURLやヘッダを利用する代わりに、APIではJSON本体を取り込み、JSON本体を返却する。利用するAPI機能が検索であっても状態変更であっても、この動作方法に変わりはない。

スケールの面に関して言えば、Dropboxのアプローチにはいくつかのメリットとデメリットがある。 DropboxのAPIは、時に厳格で規範的なRESTの性質に拘束されていない、という評価もできる。このような性質は全データのユースケースに合うものではないし、まったく誤った解釈をされてしまうことも少なくないのだ。RUST/RUBYのコントリビュータでRust for Rubyistsの作者でもあるSteve Klabnik氏は、“RESTful APIの99%はRoy Fielding氏のRESTの理念に完全には準拠していない”、と主張している。この見かけ上のRESTfulの慣習さえも破ることによって、DropboxのAPIは、いかなるセットモデルにも準拠しないものとなっている。そうすることによって、将来的に必要となる可能性のあるいかなるユースケースに対しても、APIを簡単に適応させることが可能になるのだ。しかしながら、このような柔軟性を手に入れた一方では、構造と開発者の一般的な理解を失うことになる。

HTTPステータスコードはDropbox APIの利用を考えているすべての開発者が理解し、容易に対処可能な世界共通の標準である。それに対して、レスポンス本体に格納された同社独自のステータスコードは、面倒な文字列処理を必要とする反面、さまざまなエラー状態に対するプログラム的な解釈は容易なものになる。GETとPOSTの組み合わせは、従来よりもパワフルなAPI開発の可能性を秘めてはいるものの、ユーザの視点から見てどの呼び出しがオブジェクトの状態を変更するのか、どれが純粋な検索ベースで、どれが潜在的に危険な統合型のシナリオかを判断することは難しくなる。このようなカスタムAPIアーキテクチャを導入する判断の多くには、開発者に対して、新たなAPIを扱える能力だけでなく、特にDropbox APIに関するさまざまなドメイン知識の習得を求める、という前提がある。Dropbox開発者であるF. Metsys氏はブログ記事で、Dropboxのアプローチについて、“自ら手を下さずに、利用できる範囲についてはHTTPのメリットを活用するようにしているのです”と語っている。これよってDropbox APIは、他のAPIにはない機能やデータアクセスレベルを実現できる反面、アプリケーションの統合プロセスを複雑で時間を要するものにする可能性もはらんでいる。Dropbox APIのアドホックな構造が全体的な拡張とスケールの点でプラスかマイナスか、それは今後の動向を見なければ分からない。