翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
REST と GraphQL の比較
APIs (アプリケーションプログラミングインターフェイス) は、アプリケーション間のデータ交換を容易にする上で重要な役割を果たします。前述のように、設計には GraphQL と の 2 つの顕著なアプローチAPIsが浮上していますREST。どちらもクライアントとサーバーの通信を可能にする基本的な目的を果たしますが、実装とユースケースは大きく異なります。
GraphQL と は、いくつかの主要な特徴RESTを共有します。
-
クライアントサーバーモデル : どちらもデータ交換にクライアントサーバーアーキテクチャを使用します。
-
ステートレス性 : リクエスト間でクライアントセッション情報は維持されません。
-
HTTPベース : 通常、どちらも基盤となる通信プロトコルHTTPとして を使用します。
-
リソース指向設計 : どちらも、クライアントが を介してアクセスおよび操作できるデータまたはオブジェクトを参照するリソースに関するデータ交換を設計しますAPI。
-
データ形式の柔軟性: JSONは、 XMLや などの他の形式もサポートされていますが、両方で最も一般的に使用されるデータ交換形式HTMLです。
-
言語とデータベースに依存しない : どちらも任意のプログラミング言語またはデータベース構造で動作するため、高い相互運用性があります。
-
キャッシュサポート : どちらもキャッシュをサポートしているため、クライアントとサーバーは頻繁にアクセスされるデータを保存してパフォーマンスを向上させることができます。
GraphQL と は、いくつかの基本原則を共有しながら、API設計とデータフェッチに対するアプローチが大きくREST異なります。
-
リクエスト構造とデータ取得
REST は、さまざまなHTTPメソッド (GET、POST、PUT、DELETE) を使用して リソースに対してオペレーションを実行します。これには、多くの場合、異なるリソースに対して複数のエンドポイントが必要になるため、データの取得が非効率になる可能性があります。例えば、ユーザーのデータを取得するGETオペレーションを実行すると、データのオーバーフェッチまたはアンダーフェッチが発生する可能性があります。正しいデータを取得するには、切り捨てまたは複数のオペレーションを呼び出すことができます。
GraphQL は、すべてのオペレーションに単一のエンドポイントを使用します。データの取得にはクエリ、データの変更にはミューテーションを使用します。クライアントはクエリを使用して、1 回のリクエストで必要なデータを正確に取得できるため、データ転送を最小限に抑えることでネットワークオーバーヘッドを削減できます。
-
サーバー側のスキーマ
REST はサーバー側のスキーマを必要としませんが、効率的なAPI設計とドキュメント化のためにオプションで定義できます。
GraphQL は、強く型指定されたサーバー側のスキーマを使用して、データおよびデータサービスを定義します。GraphQL Schema Definition Language (SDL) で記述されたスキーマには、各オブジェクトのオブジェクトタイプとフィールド、および各フィールドのオペレーションを定義するサーバー側のリゾルバー関数が含まれます。
-
バージョニング
REST にバージョニングが含まれていることが多くURL、複数のAPIバージョンを同時に維持できます。バージョニングは必須ではありませんが、変更の中断を防ぐのに役立ちます。
GraphQL は、下位互換性を必要とするため、明示的なバージョニングAPIなしで の継続的な進化を促進します。削除されたフィールドはエラーメッセージを返し、非推奨タグは古いフィールドを段階的に廃止して警告メッセージを返します。
-
エラー処理
REST はタイプが弱いため、エラー処理を周囲のコードに組み込む必要があります。これにより、タイプ関連のエラー (例: 数値をテキストとして解析) が自動的に識別されない場合があります。
対照的に、GraphQL は強く入力され、包括的なスキーマ定義が必要です。これにより、サービスが多くのリクエストエラーを高レベルの詳細で自動的に識別できるようになります。
-
ユースケース
REST は、以下に適しています。
-
データ要件がそれほど複雑ではない小規模なアプリケーション。
-
データおよびオペレーションがすべてのクライアントで同様に使用されるシナリオ。
-
複雑なデータクエリのニーズがないアプリケーション。
GraphQL は次の用途に適しています。
-
リクエストとレスポンスを最小限に抑えることが重要な、帯域幅が限られているシナリオ。
-
単一のエンドポイントで組み合わせる必要がある複数のデータソースを持つアプリケーション。
-
クライアントリクエストが大きく異なり、異なるレスポンス構造を期待する場合。
GraphQL と の両方を 1 つのアプリケーションRESTAPIs内で、さまざまな機能分野に使用できることに注意してください。さらに、 をアップグレードRESTfulAPIして、完全な書き換えなしで GraphQL 機能を含めることができます。例については、AWS 「データソースの GraphQL リゾルバーを構築する
方法」を参照してください。 -