オープンソース・ソフト Drupal を使った Web サイトの構築・サポート・研修

Drupal 8 の「API ファースト」を改良する:JSON API と OAuth か?

以下、緑色のテキストは訳注。 元記事(英語)のページはこちら
 

Drupal 8 の将来にとっていちばん大事なイニシアチブのひとつに「API ファースト(API-first)」がある。この部会の目的は、分離(ディカップリング)されたアプリケーションを作るための Web サービス機能を Drupal において改良することにある。僕は以前のブログ記事で Drupal の Web サービス ソリューションの現状を評価し大まかな(今後の)展望を掲げ将来に向けた道筋を描いた

前回の更新情報記事からの 5 か月の間に Drupal における Web サービスは機能と使いやすさの面で大きく前進した。このブログ記事では、その最大の改良点をいくつか論じようと思う。

API-First Building Blocks
Drupal において Web サービスを作成するカギとなる構築ブロック(構成要素)の全体像。Drupal コアは標準状態で、内部ストレージを反映した RAW JSON を外部に展開できる。また、HAL 形式での展開も可能。Waterwheel は JSON API メソッドが Waterwheel.js を通じて呼び出された場合、JSON API に依存(optional dependency)することに注意。
 

コアの REST 改良点

Drupal 8.2 リリースで、コアの REST API は、分離したアプリケーションに求められる、いくつかの重要な条件に対応した。まず(ブロック、メニューなどの)コンフィギュレーション エンティティーを REST リソースとして取得できるようになった。REST API を通じてのユーザー登録も可能だ。コアの REST 開発者体験も改善されている。REST コンフィギュレーションがシンプルになり、エラーを引き起こすリクエストに対する応答メッセージとステータス コードが改良された。

さらに、オプトインの CORS(Cross-Origin Resource Sharing)対応のおかげで、分離されたアプリケーションや他のドメインでホスティングされているサイトから Drupal のコンテンツにアクセスできるようになった(「オプトイン」は利用者の承諾を得て実行すること。「CORS」はサーバーをまたいだリソース共有)。これは特に、たとえば、JavaScript アプリケーションが AWS 上に直接ホスティングされていて、Drupal は別のプラットフォームに置かれているという場合などに役立つ。こうした進展がそろったおかげで、より豊富な機能を備えた分離アプリケーションを Drupal で作れるようになった。

これらの改良はすべて、以下の人々の懸命な取り組みのおかげでできたものだ:ウィム リーアス(Wim Leers - Acquia 社)、テッド ボウマン(Ted Bowman - Acquia 社)、ダニエル ウェーナー(Daniel Wehner - Chapter Three 社)、クレメンス トルブーム(Clemens Tolboom)、ホセ マヌエル ロドリゲス ヴェレス(José Manuel Rodríguez Vélez)、クラウス プーラー(Klaus Purer)、ジェイムス ギリランド(James Gilliland - APQC 社)、ゲイブ サリス(Gabe Sullice - Aten Design Group 社)

新興の標準としての JSON API

JSON API は JSON での REST API 仕様だ。これには、現在のコア REST API と比べて、有無を言わせぬ長所がいくつかある。第一に、JSON API には、単独のエンティティーだけでなく、そのエンティティーに結びつくすべてのリレーションシップをクエリーする標準的な方法が用意されている。また(たとえば1つの記事に紐付けされたすべてのタグをリスティングするなど)クエリー ストリング パラメーターを通じてクエリー操作を行う方法もだ。第二に、JSON API ではコンテンツ エンティティーのリストを取得できる(フィルタリング、ソーティング、ページングも含む)。片や、コアでは、この点に関して現在ある選択肢は限られている。その1つは複数のリクエストを送ることだ。それはパフォーマンスの面で望ましくない。Drupal の view をクエリーする手もあるが、それには追加の作業が必要になる。

さらに、JSON API は、JSON で REST API を作っている開発者の間で広まっているので、JavaScript コミュニティーでますます一般的になっている。Ruby on Rails と Ember の両コミュニティーにおいてもだ。端的にいって、Drupal(コミュニティー)の外における勢いは目下、HAL よりも JSON API の方にある。僕は、JSON API は試験的なコア モジュールになるべきだと信じている。潜在的には、いつか、Views ベースの REST エンドポイントや HAL などに取って代わる可能性さえあると思う。Views の REST エクスポートは、どんなときでも特定のニーズに対して有益であり続けるだろう。しかし、JSON API はクエリー操作に別途調整が不要なので、より一般的なタスクに適している。こうしたことをすべて話したうえで、JSON API を優先したらどうなるのか、僕たちは議論と評価を重ねるべきだと思う。

マテウ アグイロ ボシュ(Mateu Aguiló Bosch)とゲイブ サリス(Gabe Sullice)の努力のおかげで、Drupal 8 の JSON API モジュールはコアの試験的なモジュールと考慮されるレベルの安定度にグングン近づきある。

OAuth2 bearer token 認証

今日の分離アプリケーションの多くが直面している問題のひとつに、Drupal の REST API を利用する場合に堅固な認証メカニズムがないということがある。現在、コア REST には標準で 2 つしか選択肢がない。すなわち、クッキーに基づいた認証とベーシックな認証だ。そして、前者は Drupal サイト以外のドメインでの分離アプリケーションでは役に立たず、後者は他の仕組みと比べてセキュリティーの点で劣る。

OAuth2 は広く普及しているので、リクエストを認証する必要がある Drupal サイトにとって次のステップとなるのは理にかなっている。コア REST のベーシックな認証で利用できるものよりはセキュアなので、OAuth2 は、開発者がよりセキュアな分離 Drupal アーキテクチャーを構築するのに役立つことだろう。そうすれば、それほどセキュアではない他のアプローチはお役御免になる。

マテウ アグイロ ボシュ(Lullabot 社)が作った Simple OAuth などの OAuth2 ソリューションを試験的なコア モジュールと捉え、Drupal の REST API をもっとセキュアにできるようにするのは意味があることだろう。

Drupal の SDK エコシステム Waterwheel

「API ファースト」イニシアチブの作業は、Drupal のバックエンドを改良するだけにとどまらない。Acquia は Waterwheel.js 1.0 をオープンソースとしてリリースした。これは JavaScript 開発者用のヘルパー SDK の初回リリースだ。Waterwheel.js SDK は、JavaScript 開発者が Drupal の REST API の機能する仕組みを詳しく知らなくても、Drupal に対してリクエストを行えるようにしてくれる。たとえば、Waterwheel モジュールがあれば、リソース検出による利点が得られる。これは、自分の JavaScript アプリケーションに Drupal のデータ モデルを認識させてくれるものだ。Waterwheel.js は JSON API 拡張モジュールとも容易に統合できる。

カイル ブラウニング(Kyle Browning - Acquia 社)のおかげで、Waterwheel.swift SDK があれば、iPad、iPhone、Apple Watch、Apple TV といったアップル社デバイス用のアプリ開発者は、Drupal 駆動のアプリケーションをより素早く作れるようになった。Waterwheel エコシステムについての詳細はプレストン ソー(Preston So - Acquia 社)のブログ記事を参照のこと。

結論

この件にかかわっている大勢の貢献者が懸命に作業してくれたおかげで、「API ファースト」イニシアチブは大きな勢いで前進している。この記事のまとめは以下のようになる。

JSON API および Simple OAuth モジュールは、Drupal 8 コアに採り入れる候補になり得る。これは僕たちが議論と評価を重ねるべきことだ。

また、HAL と JSON API に対してどこからどこまでサポートするのかも議論するべきだ。それは、自分たちの時間と労力を集中するためだ。

もし、Drupal 8 で分離アプリケーションを作っている場合は、利用できるようになったコア REST API と JSON API の実装についての感想を教えてほしい。それは僕たちにとって大きなプラスになることだろう。足りない機能は何か?どんなクエリーが難しいか、または修正する必要があるか?どうやったら API をもっと要求条件に合わせられるか?このブログ記事のコメント セクションを使って、今やっていることをもっと僕たちに教えて欲しい。その体験談から僕たちは学ぶことができるだろう

もちろん、コードを書く、レビューする、パッチをテストする、あるいは単にイシュー(問題点)についての議論に参加することによって「API ファースト」イニシアチブの作業を推し進めることができるのなら話は別だ。その場合、Drupal 自体の改良だけでなく、自分たちの理想的な API ファースト バックエンドとして Drupal を使いたいと願っている開発者すべての体験を改善するのを手伝っていることになるのだから。

このブログ記事に貢献してくれたプレストン ソー(Preston So)、そして、この執筆中に意見を聞かせてくれたウィム リーアス(Wim Leers)、アンジー バイロン(Angie Byron)、テッド ボウマン(Ted Bowman)、クリス ハンパー(Chris Hamper)に特別な感謝の意を表したい。