GraphQL と REST の違いはなんですか?
GraphQL と REST は、インターネット上でデータを交換するための API を設計するための 2 つの異なるアプローチです。REST を使用すると、クライアントアプリケーションは、インターネットの標準通信プロトコルである HTTP 動詞を使用してサーバーとデータを交換できます。一方、GraphQL は、クライアントアプリケーションがリモートサーバーにデータをリクエストする方法の仕様を定義する API クエリ言語です。リクエストの定義をサーバー側のアプリケーションに頼らなくても、API 呼び出しで GraphQL を使用できます。GraphQL と REST はどちらも、現代のアプリケーションのほとんどを支える強力なテクノロジーです。
GraphQL と REST にはどのような類似点がありますか?
GraphQL と REST はどちらも、クライアントサーバーモデルの異なるサービスやアプリケーション間でのデータ交換を可能にする一般的な API アーキテクチャスタイルです。
API を使用すると、次のようなデータへのアクセスとデータ操作が容易になります。
- クライアントは、サーバー上の 1 つまたは複数のエンドポイントに API リクエストを送信します
- サーバーは、データ、データステータス、またはエラーコードを含むレスポンスを返します
REST と GraphQL では、API を介して別のアプリケーション、サービス、またはモジュール上のデータを作成、変更、更新、削除できます。 REST を使用して開発された API は、RESTful API または REST API として知られています。GraphQL で開発されたものは単に GraphQL API です。
フロントエンドチームとバックエンドチームは、これらの API アーキテクチャを使用して、モジュール式でアクセスしやすいアプリケーションを作成します。API アーキテクチャを使用すると、システムの安全性、モジュール性、拡張性を維持できます。また、システムのパフォーマンスが向上し、他のシステムとの統合も容易になります。
次に、GraphQL と REST のその他の類似点について説明します。
アーキテクチャ
REST と GraphQL はどちらも、いくつかの一般的な API アーキテクチャ原則を実装しています。たとえば、両者が共有する原則は次のとおりです。
- どちらもステートレスなので、サーバーはリクエスト間のレスポンス履歴を保存しません
- どちらもクライアント/サーバーモデルを使用しているため、 1 つのクライアントからのリクエストに対して 1 つのサーバーからレスポンスが返されます
- HTTP が基盤となる通信プロトコルであるため、どちらも HTTP ベースです
リソースベースのデザイン
REST と GraphQL はどちらも、リソースを中心にデータ交換を設計しています。リソースとは、クライアントが API を介してアクセスして操作できるあらゆるデータまたはオブジェクトを指します。各リソースには、一意の ID (URI) と、クライアントが実行できる一連の操作 (HTTP メソッド) があります。
たとえば、ユーザーがポストを作成および管理するソーシャルメディア API を考えてみましょう。リソースベースの API では、ポストはリソースになります。これは /posts/1234 といった、一意の識別子を含みます。また、REST でポストを取得する GET や GraphQL でポストを取得するクエリなど、一連の操作があります。
データ交換
REST と GraphQL はどちらも同様のデータ形式をサポートしています。
JSON は、すべての言語、プラットフォーム、システムが理解できる最も一般的なデータ交換形式です。サーバーは JSON データをクライアントに返します。XML や HTML など、他のデータ形式も利用可能ですが、あまり使われていません。
同様に、REST と GraphQL はどちらもキャッシュをサポートしています。そのため、クライアントとサーバーは頻繁にアクセスされるデータをキャッシュして通信速度を上げることができます。
言語とデータベースの中立性
GraphQL と REST API はどちらも、クライアント側とサーバー側の両方で、あらゆるデータベース構造とプログラミング言語で動作します。これにより、どのアプリケーションとも高度に相互運用できます。
GraphQL はどのような REST の制限を克服しようとしていますか?
GraphQL は、新興のソーシャルメディアプラットフォームにおけるスピードへのニーズに応えて、2012 年に登場しました。デベロッパーは、REST のような既存の API アーキテクチャは、ニュースフィードを効率的に生成するにはあまりにも長く、構造化されすぎていることに気付きました。
次に、彼らが直面したいくつかの課題について説明します。
固定構造データ交換
REST API では、リソースを受け取るために、クライアントのリクエストは固定された構造に従う必要があります。この厳格な構造は使いやすい一方で、必要なデータを正確に交換する手段として、必ずしも効率的であるとは限りません。
オーバーフェッチとアンダーフェッチ
REST API は常にデータセット全体を返します。たとえば、REST API の人物オブジェクトから、その人物の名前、生年月日、住所、電話番号を受け取ります。電話番号だけが必要な場合でも、これらのデータをすべて受け取ります。
同様に、個人の電話番号と最終購入日を知りたい場合は、複数の REST API リクエストが必要になります。URL /person は電話番号を返し、URL /purchase は購入履歴を返します。
ソーシャルメディアのデベロッパーは API リクエストを処理するためだけに大量のコードを書かなければならず、それがパフォーマンスとユーザーエクスペリエンスに影響を与えました。
GraphQL はクエリベースのソリューションとして登場しました。クエリは 1 回の API リクエストとレスポンス交換だけで正確なデータを返すことができます。
主な相違点: GraphQL とREST
REST API はアプリケーション通信のアーキテクチャコンセプトです。一方、GraphQL は仕様であり、API クエリ言語であり、ツールのセットでもあります。GraphQL は HTTP を使用して単一のエンドポイント上で動作します。
さらに、REST の開発は、新しい API の作成に重点を置いてきました。一方、GraphQL は API のパフォーマンスと柔軟性に重点を置いてきました。
次に、さらにいくつかの相違点を以下に示します。
クライアント側リクエスト
REST リクエストの動作には次のようなものがあります。
- アクションを決定する HTTP 動詞
- HTTP 動詞の処理対象となるリソースを識別する URL
- 既存のサーバー側リソース内でオブジェクトを作成または変更する場合に解析するパラメーターと値
たとえば、GET を使用してリソースから読み取り専用データを取得し、POST を使用して新しいリソースエントリを追加し、PUT を使用してリソースを更新します。
対照的に、GraphQL リクエストの動作には次のようなものがあります。
- 読み取り専用データを取得するためのクエリ
- データ修正用のミューテーション
- イベントベースまたはストリーミングデータの更新を受け取るためのサブスクリプション
データ形式は、サーバー側のスキーマに一致するオブジェクトやフィールドなど、サーバーがデータをどのように返すかを記述します。新しいデータを入力することもできます。内部的には、GraphQL はすべてのクライアントリクエストを POST HTTP リクエストとして送信します。
クライアントに返されたデータ
REST アーキテクチャでは、データはサーバーによって指定されたリソース全体構造でサーバーからクライアントに返されます。次の例は、REST と GraphQL で返されるデータを示しています。
REST で返されるデータの例
REST では、GET /posts は以下を返します。
[
{
"id": 1,
"title": "First Post",
"content": "This is the content of the first post."
},
{
"id": 2,
"title": "Second Post",
"content": "This is the content of the second post."
},
{
"id": 3,
"title": "Third Post",
"content": "This is the content of the third post."
}
]
GraphQL で返されるデータの例
GraphQL を使用すると、クライアントから与えられた構造で指定されたデータのみが返されます。
GET /graphql?query{post(id: 1) {id title content}} は最初のポストのみを返します。
{
"data": {
"posts": [
{
"id": "1",
"title": "First Post",
"content": "This is the content of the first post."
},
]}}
サーバー側スキーマ
GraphQL は、REST API とは異なり、サーバー側のスキーマを使用してデータやデータサービスを定義します。
GraphQL スキーマ定義言語で書かれたスキーマには、次のような詳細が含まれています。
- 各オブジェクトに属するオブジェクトタイプとフィールド
- 各フィールドの操作を定義するサーバー側リゾルバー関数
スキーマは、システム上で利用可能なすべてのデータと、クライアントがそのデータにアクセスまたは変更する方法を説明するタイプを明示的に定義します。
一方、REST API はサーバー側のスキーマを必要としません。ただし、API 設計、文書化、およびクライアント開発を効率化するために、オプションで定義することもできます。
バージョニング
API の進化に伴い、そのデータ構造や操作が変更する可能性があります。これらの変更をクライアントが把握していないと、システムが壊れたり、未知のエラーが発生したりする可能性があります。
REST API では、https://example.com/api/v1/person/12341 のように、この問題を解決するために URL にバージョニングが含まれていることがよくあります。 ただし、バージョニングは必須ではないため、エラーにつながる可能性があります。
GraphQL には API の下位互換性が必要です。そのため、削除されたフィールドはエラーメッセージを返し、非推奨のタグが付いたフィールドは警告を返します。
エラー処理
GraphQL は厳密に型指定された API アーキテクチャであるため、スキーマ内のデータ、構造、データ操作の詳細な説明が必要です。スキーマの詳細レベルにより、システムは自動的にリクエストエラーを識別し、有用なエラーメッセージを表示できます。
REST API は型指定が弱いため、エラー処理を周囲のコードに組み込む必要があります。たとえば、PUT リクエストが数値を整数ではなくテキストとして解析した場合、システムはエラーを自動的に識別しません。
使用すべき場面の比較、GraphQL とREST
GraphQL と REST API は同じように使用することができます。ただし、どちらか一方が適しているユースケースもあります。
たとえば、次のような考慮事項がある場合は、GraphQL の方が適している可能性があります。
- 帯域幅に制限があり、リクエストとレスポンスの数を最小限に抑えたい
- 複数のデータソースがあり、それらを 1 つのエンドポイントにまとめたい
- クライアントのリクエストが大きく異なり、求められるレスポンスも大きく異なる
一方、次のような考慮事項がある場合は、REST の方が適している可能性があります。
- アプリケーションの規模が小さく、データがそれほど複雑ではない
- すべてのクライアントが同じように使用するデータと操作がある
- 複雑なデータクエリの必要がない
また、さまざまな機能分野に対応する GraphQL API と REST API の両方を使用して 1 つのアプリケーションを構築することもできます。
同じ API で GraphQL と REST の両方を使用する方法
RESTful API から GraphQL API へのアップグレードは、完全な書き換えを実行することなく可能です。
プロセスの概要は次のとおりです。
- RESTful API のデータモデルを理解します。そのためには、各 URL リソースのデータの形を調べます。
- データモデルから GraphQL スキーマを記述します。
- クライアントがデータに対して実行する操作を決定し、それらをスキーマに含めます。
- スキーマ内の各フィールドのサーバー側コードにリゾルバー関数を構築します。
- リゾルバーとスキーマを使用して GraphQL サーバーを作成します。
この後、クライアントは GraphQL または REST のいずれかを使用して API と通信できるようになります。
相違点の要約: REST とGraphQL
REST |
GraphQL |
|
内容 |
REST は、クライアントとサーバー間の構造化されたデータ交換を定義する一連のルールです。 |
GraphQL は、API を作成および操作するためのクエリ言語、アーキテクチャスタイル、およびツールのセットです。 |
こんな方に最適 |
REST は、リソースが明確に定義されている単純なデータソースに適しています。 |
GraphQL は、大規模で複雑な、相互に関連するデータソースに適しています。 |
データアクセス |
REST には、リソースを定義する URL 形式の複数のエンドポイントがあります。 |
GraphQL には単一の URL エンドポイントがあります。 |
戻りデータ |
REST は、サーバーによって定義された固定の構造でデータを返します。 |
GraphQL は、クライアントによって定義された柔軟な構造でデータを返します。 |
データの構造と定義方法 |
REST データは弱い型指定です。そのため、クライアントは、フォーマットされたデータが返されたときにどのように解釈するかを決定する必要があります。 |
GraphQL データは厳密に型指定されています。そのため、クライアントは、あらかじめ決められた、相互に理解し合える形式でデータを受け取ります。 |
エラーチェック |
REST では、クライアントは返されたデータが有効かどうかを確認する必要があります。 |
GraphQL では、通常、無効なリクエストはスキーマ構造によって拒否されます。その結果、エラーメッセージが自動生成されます。 |
AWS は GraphQL と REST の要件をどのようにサポートできますか?
Amazon Web Services (AWS) は、より適切に管理された API を構築して提供するのに役立ちます。
AWS AppSync はサーバーレス GraphQL とパブリッシュ/サブスクライブ (Pub/Sub) API を作成します。単一のエンドポイントでデータを安全にクエリ、更新、公開できるため、アプリケーション開発が簡素化します。
AWS AppSync では、クライアントが以下を実行できるようにする API を作成します。
- SQL、NoSQL、検索データ、REST エンドポイント、マイクロサービスなどの複数のデータソースを 1 回のネットワーク呼び出しで操作可能
- モバイル、ウェブアプリケーション、およびクラウド間でデータを自動的に同期
- バックエンドから接続されたクライアントへ、または接続されたクライアント間でデータをブロードキャスト
- モノのインターネット (IoT) データにアクセスして、モバイルまたはウェブアプリケーションでリアルタイムのダッシュボードを構築
同様に、Amazon API Gateway は、API の作成、公開、保守、監視、保護を、その規模に関わらず簡単に行えるようにする、フルマネージド型のサービスです。
API Gateway を使用することで得られるメリットは次のとおりです。
- API リクエストとレスポンスの両方で高速パフォーマンスを実現
- API へのアクセス許可
- 同じ API の複数のバージョンを同時に実行して、新しいバージョンのすばやい反復、テスト、リリース
- パフォーマンスメトリクスと API 呼び出し、データレイテンシー、およびエラー率に関する情報の監視
今すぐアカウントを作成して、AWS で GraphQL と REST の使用を開始しましょう。