BT

GraphQL対REST - 考慮すべき点

| 作者: Andrew Morgan フォローする 3 人のフォロワー , 翻訳者 h_yoshida フォローする 1 人のフォロワー 投稿日 2017年8月16日. 推定読書時間: 4 分 |

原文(投稿日:2017/07/08)へのリンク

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

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

  • 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においてユーザの設計に問題があるとすれば、他のどのタイプを選択しても設計上の問題が発生する可能性が高い、とも述べている。講演の全映像はオンラインで確認することができる。集約された内容はブログ記事に紹介されている。

この記事を評価

採用ステージ
スタイル

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT