Drupal は API 優先プラットフォームに向かってどう進化し続けるか

Drupal コアの API ファースト イニシアチブに関する前回の進捗（しんちょく）レポートを書いてから、もう 1 年になる。この 1 年で重要な進展があったので新しいレポートをまとめてみた。

2 年半前、僕たちは REST API を搭載した Drupal 8.0 を公開した。それは Drupal が API 優先プラットフォームへと進化していく開始点を刻むことになった。そのときからリリースされた 5 つの Drupal 8 バージョンでは毎回、Web サービス API が大きく改良された。

僕は 5 年前の時点で Drupal 8 に Web サービスを加えようと提唱していたが、今日では、その点に関して当時よりもさらに確信を抱いている。重要な市場トレンドがこの戦略を裏打ちしているのだ。それは、他のテクノロジー ソリューションとの統合であり、新しいデバイスや新しい（マーケティング）チャンネルの急増であり、JavaScript フレームワークの普及増であり、といった具合だ。

実際のところ、僕は Drupal の成功にとってはこの機能が決定的だと信じているので、Acquia はもう数年来、Drupal の Web サービス API に貢献するフルタイムのソフトウェア開発者を（人月換算で）若干名、提供してきた。さまざまなコミュニティー貢献者に対して行っている資金援助とは別にだ。現在、Drupal Web サービスには 2 名の Acquia 開発者がフルタイムで取り組んでいる。

Drupal コアの REST API

Drupal 8.0 に備わっていたのは基本的な REST API だったが、その能力、頑強性、テスト カバレッジ（テスト網羅率）を改良しようとコミュニティーは頑張った。5 か月前に公開された Drupal 8.5 には新しい REST API 機能と大幅な改善が加えられていた。9 月にリリースされる予定の Drupal 8.6 にもまた多数の新しい改良点が加わる予定だ。

Drupal 8.6 で改良された点のひとつは、REST モジュールが API ファーストのコードを個々のモジュールに提供するのではなく、そのコードを個々のモジュールに移動したことだ。これは一見、大きな変更には思われないかもしれないが、実は大きなことだ。長期的には、個々のモジュールに API を提供する中心的な API モジュールに依存することなく、すべての Drupal モジュールが Web サービス API を搭載してリリースされるようにするべきだ。そうすれば、変更する場合、REST API クライアントに対するインパクトを考慮せざるを得なくなる。

Drupal 8.6 の REST API で僕たちが改良したもう一つの点はファイル アップロードのサポートだ。ファイル アップロードのサポートについて僕たちがどれだけ考え、配慮したかを理解するには（ウィム リーアス（Wim Leers）のブログ記事）「API-first Drupal: file uploads!」を参照されたし。ファイル アップロードをセキュア（安全）にして、大きなファイルに対応し、パフォーマンスを最適化し、良好な開発者体験も提供するのは大変な仕事だ。

JSON API

JSON API モジュールをコアに採り入れることは重要だ。それは、JavaScript コミュニティーにおいて JSON API がどんどん広まっているからだ。

元々、僕たちは Drupal 8.3 に JSON API を追加する予定だったのだが、それは実現しなかった。その計画を立てることにした当初、Drupal の Routing、Entity、Field、Typed Data といったサブシステムは API ファーストの世界へ向けた用意ができておらず、その用意がどのくらい足りないのかということに僕たちはやっと気づき始めたところだったからだ。そうした基礎となるサブシステムを整えて形をまとめるには 2017 年末までかかった。

REST API が成熟するのを妨げたのと同じ弱点が JSON API、GraphQL や他の API ファースト モジュールにも現れた。それに対する回避策を加えるのではなく、それを根本から適切に解決するのは時間がかかるものだ。しかし、このアプローチは、より強力な API ファースト エコシステムを作ることになるし、（結果的に）今後の進展が加速することにもなる。

この遅れにもかかわらず、JSON API チームは信じられないほどの進歩を達成してきた。直近 6 か月の間だけでも彼らは 15 バージョンのモジュールをリリースした。また、広範なテスト カバレッジ、JSON API 仕様への準拠改善、多数の安定性向上など、息をのむほどのペースで改良を繰り出してきた。

Drupal コミュニティーはこれらの改良を熱望していたので、JSON API モジュールの使用数は 2018 年の前半だけで 50 パーセント増加した。モジュールの使用数が増え、未解決イシュー（問題点）の総数が減ったという事実は、JSON API モジュールが安定し、成熟したという証拠になるだろう。

僕自身は、この普及率の上昇、開発ペースの速さ、JSON API モジュールの成熟度に胸躍らせているものの、僕たちは JSON API を Drupal 8.6 に試験的モジュールとして加えないことを決めた。その代わり、Drupal 8.7 開発サイクルの初期段階でコアに加え、Drupal 8.7 のリリース時に安定バージョンとして公開する予定でいる。

GraphQL

Drupal コアに GraphQL を加えることを検討すべきだと僕が提唱し始めてもう 2 年以上になる。

コア コミッターとコア コントリビューターはまだ GraphQL を優先課題のひとつにはしていないが、貢献モジュール GraphQL では大きな進展がたくさんあったので最初の安定リリース バージョンに近づいた。まだ安定リリースはないにもかかわらず、このモジュールの普及率は 2018 年前半で実に 200 パーセントも増えた（ただ、そうはいっても使用サイト数は数千ではなく数百の単位だが）。

また、GraphQL の仕様にやっと新版が出て、もうライセンス使用に関する懸念に足を引っ張られることがなくなったのもうれしいことだ。これはオープンソース コミュニティーにとって素晴らしい知らせであり、GraphQL の普及にとってプラスになることはあってもマイナスになることはない。

正直に認めるが、GraphQL をコアに加えるという僕の推奨案に GraphQL モジュールのメンテナーが賛同しているかどうか、僕は知らない。というのも、REST API を安定化させ、JSON API サポートを追加するまではそうした話をしないよう、意図的に先送りしてきたからだ。それでも、僕はまだ、将来リリースされる Drupal 8 に GraphQL モジュールが加わったところを是非見たいと思っている。僕たちの（最終）決定がどうなるかはともかく、ひとつの API ファースト Drupal にとって GraphQL は重要なコンポーネント（構成要素）だし、その進展を僕は楽しみにしている。

OAuth 2.0

Web サービス API の更新は「認証」というトピックに触れることなしに完了することはあり得ないだろう。昨年、僕は、理屈からいって Drupal コアに加わる次のモジュールは OAuth 2.0 であろうという仕組みを説明した。

その後、OAuth 2.0 モジュールは見直され、自身の OAuth 2.0 実装を排除し、PHP League の OAuth 2.0 Server を採用することになった。そちらの実装はインストール数が 500 万を超えるほど広く利用されている。これによって、自分たちでメンテしなくてはならない Drupal 専用の実装を用意するのではなく、ほかの人たちがメンテしてくれるデファクト スタンダード（事実上の標準）の実装を利用することができる。

API ファースト エコシステム

僕は個人的に REST API と JSON API の作業にいちばん集中していて、それに GraphQL が続く「二番手」の状態だが、ほかにもたくさんの API ファースト モジュールが開発されているのを見るのは心強い。

• OpenAPI：標準ベースの API ドキュメンテーション用。現在、ベータ 1。
• JSON API Extras：JSON API をサイト独自のニーズに合わせる（フィールドのエイリアス化、フィールドの削除など）。
• JSON-RPC：Drupal サイト管理の共通アクションを実行するのに役立てる。たとえば、キャッシュをクリアするなど。
• まだ、ほかにもたくさんある。

まとめ

みんなも僕と同じくらい、来（きた）る Drupal 8.6 リリースと、それがもたらす数々の Web サービス改良にワクワクしていたらいいなと思う。Drupal を API ファーストにするためになされた継続的な努力と、これらのプロジェクトやイニシアチブが実現した信じられないほどの勢いに対する貢献のすべてにとても感謝している。

このブログ記事に貢献してくれたウィム リーアス（Wim Leers）とゲイブ サリス（Gabe Sullice）、そして、この執筆中に意見を聞かせてくれたマーク ウィンベリー（Mark Winberry）、ジェフ ビーマン（Jeff Beeman）に謝意を表したい。