REST vs GraphQL: どちらのAPIパラダイムを選ぶか
RESTはHTTPセマンティクスを持つ固定的なリソースエンドポイントを公開する。GraphQLは、クライアントが必要なフィールドだけを正確に要求できる単一のエンドポイントを公開します。
RESTはリソースをURLにマッピングし、HTTP caching、status code、シンプルさに依拠しますが、複雑なクライアントに対してはover-fetchやunder-fetchが起こり得ます。GraphQLはクライアントが型付きschemaに対して正確なクエリを指定でき、round tripとover-fetchingを減らしますが、サーバー側の複雑さとより厄介なcachingという代償があります。RESTはシンプルさとHTTPネイティブなcachingを、GraphQLは柔軟でクライアント主導のデータ取得を重視します。
| REST | GraphQL | |
|---|---|---|
| エンドポイント | 多数のリソース | 単一のエンドポイント |
| データ取得 | 固定的な形状 | クライアントが指定 |
| Caching | HTTPネイティブ | カスタム / persisted |
| Schema | OpenAPI（オプション） | 組み込み、型付き |
| 最適な用途 | シンプル/cache可能なAPI | 複雑で多様なクライアント |
ユースケースとトレードオフ
RESTはCRUDスタイルのAPI、公開エンドポイント、そしてHTTP cachingとシンプルさの恩恵を受けるあらゆるものに適しています。GraphQLは、多数のround tripなしに柔軟で集約されたデータを必要とするリッチなクライアント（モバイル、dashboard）に適しており、resolver、caching、クエリコスト制御の複雑さを許容します。
CIにおいて
RESTのpipelineはOpenAPIを検証し、契約テストを実行します。GraphQLのpipelineはschemaを確認し、型付きクライアントのためにcodegenを実行し、互換性を壊すschema変更を防ぎます。どちらもマネージドrunnerで動作し、より高速なrunnerはcodegenとschema確認のステップを短縮します。
結論
シンプルでcache可能なリソース指向のAPIならREST。多数のソースから柔軟かつ正確なデータ取得を必要とする複雑なクライアントならGraphQL。多くのチームは公開/シンプルなAPIにRESTを維持し、クライアントのデータ要求が多様で集約が多い場面でGraphQLを採用します。