GraphQL対REST - 考慮すべき点

Amaud Lauret氏がAPI Days Parisで、GraphQLとRESTful HTTP APIの長所と短所について論じた。どちらを採用すべきかは状況次第であり、この２つの間には数多くのトレードオフが存在する、というのが氏の結論だ。

GraphQLはAPI用の問合せ言語である。Facebookが開発してオープンソース公開したもので、RESTの代替手段として見ることができる。AXA BanqueのAPIアーキテクトであるLauret氏はこの２つを比較して、次のような点を指摘した。

• GraphQLは、必要なデータすべてを単一のクエリで取得可能にすることにより、ネットワークホップを削減する。
• GraphQLはWYSIWYGモデルであるため、クライアント側の参照コードでのエラーが少なくなる。
• RESTful HTTPはステータスコードとHTTP動詞を使用することにより、一貫性と予測可能性を向上させている。
• Hypermediaは、API使用時のリソースの関係性を“発見”可能にすることにより、RESTfulなコンシューマの実装を容易にしてくれる。
• HTTPはキャッシュを実装済みだが、GraphQLはそうではない。
• GraphQLはコンシューマ用のスキーマを提供するという点では便利だが、インターフェース説明はAPI資料ではない点に注意が必要だ。

Lauret氏はGpaphQLのおもなメリットとして、それがWYSIWYGモデルであることをあげている。これはつまり、クエリ結果の構造がクエリ自体の構造を正確にマップしているという意味であり、コンシューマが応答のアンマーシャル(unmarshal)を試みる時のエラーの可能性を低減することができる。

氏はさらに、GraphQLモデルがネットワークホップ数を少なくする点を説明した。RESTfulなHTTP APIでは、リソースとサブリソースが異なるエンドポイントに存在する場合があるため、すべてのデータを取得するためには複数のリクエストが必要になる。しかしGraphQLならば、単一のクエリで取り出し可能だ。実際に、システム内のすべてのリソースを一度に問い合わせることもできる。

Lauret氏はこのモデルが強力であると考える一方で、単一エンドポイントのアプローチによって一貫性や予測可能性が失われる可能性についても触れている。RESTfulなHTTP APIに比較した場合、もっとも明白な損失のひとつはHTTP動詞の活用だ。例えばRESTful HTTPでは、コンシューマがリソースにDELETE要求を送信することにより、そのオペレーションが安全かつ冪等であること、さらにはリソースの削除を意図していることが分かる。

Lauret氏はさらに、HTTPステータスコードの利用という予測可能性の損失についても指摘している。RESTfulなHTTP APIであれば、マシンと人のいずれに対しても可読性を有しているものだ。この例としては、リソースを見つけられない場合の404、コンシューマがアクセスできない場合の403、といったステータスコードがあげられる。

RESTではさらに、ハイパーメディアの利用によって、コンシューマがAPIをトラバースする際にリンクや関連リソースを見つけ出すことが可能となっている。これによってリンク構築などの必要がなくなり、クライアントにはリソースの関係についての情報が提供される。GraphQLがデータのみに焦点を当てるため、開発者はドキュメントに依存しがちになる、とLauret氏は説明している。

Lauret氏はまた、HTTPのRESTful APIが標準的なHTTPキャッシュを利用している点も指摘している。このキャッシュはすでにWebアーキテクチャの一部となっている。GraphQLでは、コンシューマ自身で独自のキャッシュ実装を処理しなければならない場合もある。これに伴って、本来ならば回避できた余分な責任の発生する可能性がある。

GraphQLのメリットとしてLauret氏が最後にあげたのは、実行時に取得可能なスキーマの提供だ。この情報は、クエリが実行可能かどうかをクライアントが判別する上で役に立つ。ただしLauret氏は、インターフェース定義は資料ではなく、GraphQLは必ずしもAPIのドキュメントに関わる問題を解決するものではない、という点を警告している。

結論としてLauret氏は、万能の解決策というものは存在しないと考えている。現在の要件に対して最も合ったものを選択することが必要なのだ。また氏は、共通する部分が多いことを理由に、あるタイプのAPIにおいてユーザの設計に問題があるとすれば、他のどのタイプを選択しても設計上の問題が発生する可能性が高い、とも述べている。講演の全映像はオンラインで確認することができる。集約された内容はブログ記事に紹介されている。