GraphQLとREST APIの違い

APIは、ソフトウェア・コンポーネントが対話し、データがインターネット上を流れるパイプとして、現代のWebサービスの生命線です。SOAP（Webサービス・メッセージング・プロトコル）やREST（アーキテクチャー・スタイル）、 GraphQL（プログラミング言語とツール）などのAPIテクノロジーは、サードパーティーのデータとサービスの統合を可能にし、ソフトウェア開発を簡素化します。APIを使用すると、企業は従業員やビジネス・パートナー、ユーザーに安全なサービス機能とデータ交換を提供できます。

APIには多くの種類がありますが、近年ではREST（representational state transfer）とGraphQLという2つの主要パラダイムに関する議論が主流となっています。どちらもさまざまなメリットがあるため、世界中のネットワーキング・プロジェクトに導入されています。ただし、データ・トラフィックの管理方法が大きく異なっています。ここでは、これらの違いを分析し、企業がRESTやGraphQL APIを使用してネットワークを最適化する方法について説明します。

REST APIとGraphQL APIをそれぞれ理解するには、両者を比較する必要があります。

REST

2000年代初頭に開発されたRESTは、ネットワーク化されたハイパーメディア・アプリケーション用の構造化されたアーキテクチャー・スタイルであり、ステートレスなクライアント/サーバーのキャッシュ可能な通信プロトコルを使用するように設計されています。REST APIは、RESTful APIとも呼ばれ、RESTアーキテクチャーのドライバーです。

REST APIは、URI（一意のリソース識別子）を使用してリソースをアドレス指定します。REST APIは、さまざまなエンドポイントでネットワーク・リソースに対してCRUD（「create（作成）」、「read（読み取り）」、「update（更新）」、「delete（削除）」）オペレーションを実行することで機能します。メディア・タイプまたはMIMEタイプという事前定義されたデータ形式に基づいて、クライアントに提供するリソースの形状とサイズを決定します。最も一般的な形式は、JSONとXML（場合によってはHTMLやプレーン・テキスト）です。

クライアントがリソースを要求すると、サーバーがクエリーを処理し、そのリソースに関連するすべてのデータを返します。応答には、「200 OK」（RESTリクエストが成功した場合）や「404 見つかりません」（リソースが存在しない場合）などのHTTP応答コードが含まれます。

GraphQL

GraphQLは、Facebookが2012年に社内で開発したクエリー言語およびAPIランタイムであり、 2015年にオープンソース化されました。

GraphQLは、GraphQLスキーマ定義言語で記述されたAPIスキーマによって定義されます。 各スキーマは、ユーザーが照会または変更できるデータの種類と、それらのタイプ間の関係を指定します。リゾルバーは、スキーマ内の各フィールドをサポートします。リゾルバーは、GraphQLのクエリーやミューテーション、サブスクリプションをデータに変換し、データベースやクラウド・サービスその他のソースからデータを取得するための指示を提供します。リゾルバーは、データ形式の仕様も提供し、システムがさまざまなソースからのデータをつなぎ合わせられるようにします。

通常、複数のエンドポイントを使用してデータを取得し、ネットワーク操作を実行するRESTとは異なり、GraphQLは、クライアントが要求しているものに関係なく、クライアントがGraphQLリクエストを送信する単一のエンドポイントを使用してデータ・モデルを公開します。次に、APIはリソース・プロパティーにアクセスし、リソース間の参照をたどって、クライアントがGraphQLサーバーに1度クエリーすることで必要なデータをすべて取得します。

GraphQL APIとREST APIはどちらも、クライアントが実行できる操作を決定するHTTPメソッド（PUTリクエストやGETリクエストなど）を使用するリソースベースのデータ交換です。ただし、この2つには、GraphQLの普及だけでなく、RESTfulシステムが持続力を発揮できる理由も説明する重要な違いが存在します。

GraphQLは、RESTに加えて、より効率的で柔軟な機能を提供します。 GraphQL APIは、特にフロントエンド・チームとバックエンド・チーム間のコラボレーションを促進する機能を備えているため、RESTful環境からのアップグレードとして見なされることがよくあります。GraphQLは、組織のAPI導入の論理的な次のステップを提供し、RESTで発生しがちな問題の修正を可能にします。

ただし、RESTは長い間APIアーキテクチャーの規格であり、多くの開発者やアーキテクトが依然としてITネットワークの管理にRESTful構成に依存しています。したがって、この2つの違いを理解することは、組織のIT管理戦略に不可欠です。

REST APIとGraphQL APIは、以下の管理方法の点で異なります。

データ取得

RESTは複数のエンドポイントとステートレスな対話に依存しており、すべてのAPIリクエストが他のリクエストとは独立して新しいクエリーとして処理されるため、クライアントはリソースに関連付けられたすべてのデータを受け取ります。クライアントがデータのサブセットしか必要としない場合でも、すべてのデータを受信します（オーバーフェッチ）。また、クライアントが複数のリソースにまたがるデータを必要とする場合、RESTfulシステムでは、最初のリクエストからのデータ取得が不十分な点（アンダーフェッチ）を補うために、クライアントが各リソースに個別にクエリーを実行することがよくあります。GraphQL APIは、単一のGraphQLエンドポイントを使用して、単一のリクエストから1回の往復で正確で包括的なデータ応答をクライアントに提供し、オーバーフェッチやアンダーフェッチの問題を排除します。

バージョン管理

RESTアーキテクチャーでは、チームはAPIをバージョン管理してデータ構造を変更し、システムエラーやエンドユーザーへのサービスの中断を防ぐ必要があります。言い換えれば、開発者は変更を行うたびに新しいエンドポイントを作成する必要があり、その結果、複数のAPIバージョンが作成され、保守が複雑になる可能性があります。GraphQLは、クライアントがクエリでデータ要件を指定できるため、バージョン管理の必要を低減させます。サーバーに新しいフィールドが追加されても、そのフィールドが必要ないクライアントには影響しません。逆に、フィールドが非推奨となっても、クライアントはクエリーが更新されるまでフィールドを引き続き要求できます。

エラー処理

REST APIは、HTTPステータス・コードを使用してリクエストのステータスまたは成功を示す必要があり、各ステータス・コードには特定の意味があります。成功したHTTPリクエストは200ステータス・コードを返します。クライアント・エラーでは400ステータス・コード、サーバー・エラーでは500ステータス・コードが返されることになります。

一見すると、このステータス・レポートのアプローチはより単純に見えますが、特にエラーが発生した場合、HTTPステータス・コードがAPI自体よりもウェブユーザーにとって有益であることが多いです。RESTにはエラーの仕様がないため、APIエラーはトランスポート・エラーとして表示される場合と、ステータス・コードがまったく表示されない場合があります。このダイナミクスにより、担当者はステータス文書に目を通し、エラーの意味や、エラーがインフラストラクチャー内でどのように伝達されるかを理解する必要があります。

GraphQL APIでは、すべてのリクエストが、エラーが発生したかどうかに関係なく、200 OKのステータス・コードを返します。これは、エラーがHTTPステータス・コードを使用して伝達されないためです（トランスポート・エラーを除く）。代わりに、システムはデータとともに応答本文のエラーを伝達するため、クライアントがデータ・ペイロードを解析してリクエストが成功したかどうかを判断する必要があります。

とはいえ、GraphQLにはエラーの仕様があるため、APIエラーとトランスポート・エラーは容易に区別できます。エラーの正確な性質は、応答本文の「エラー」エントリーに表示されるため、これに対するGraphQL APIの構築に適しています。

リアルタイム・データ

RESTにはリアルタイム更新の組み込みサポートがありません。アプリにリアルタイム機能が必要な場合、開発者は通常、ロング・ポーリング（クライアントが新しいデータを得るために繰り返しサーバーをポーリングすること）やサーバー送信イベントなどのテクニックを実装しなければならず、アプリケーションをさらに複雑にします。

ただし、GraphQLには、サブスクリプションによるリアルタイム更新のサポートが組み込まれています。サブスクリプションはサーバーへの安定した接続を維持し、特定のイベントが発生するたびにサーバーがクライアントに更新をプッシュできるようにします。

ツールと環境

REST環境は、開発者が利用できる広範なツールやライブラリー、フレームワークを備えて確立されています。しかし、REST APIとの作業には、チームが複数のエンドポイントをナビゲートし、各API固有の慣例やパターンを理解する必要があります。

GraphQL APIは比較的新しいものですが、GraphQL環境はその導入以来大幅に成長し、サーバーとクライアント双方の開発でさまざまなツールやライブラリーが利用できるようになりました。GraphiQLやGraphQL Playgroundのようなツールは、GraphQL APIの探索とテストに向けに強力なブラウザ内の統合開発環境（IDE）を提供しています。さらに、GraphQLはコード生成を強力にサポートしているため、クライアント側の開発が簡素化されます。

キャッシング

REST APIは、API呼び出しをキャッシュするためにeTagsや最終変更ヘッダーのようなメカニズムに依存しています。これらのキャッシュ戦略は効果的ではあるものの、実装が複雑で、すべてのユースケースに適しているとは限りません。

GraphQL APIは、クエリーの動的な性質により、キャッシングがさらに困難になることがあります。ただし、永続化クエリーや応答キャッシング、サーバー側キャッシングをデプロイすることで、これらの課題が軽減され、GraphQLアーキテクチャーでのより広範なキャッシング作業を合理化できます。

REST APIもGraphQL APIも本質的に優れているわけではありません。これらは、さまざまなタスクに適したさまざまなツールです。

RESTは一般的に実装が簡単で、厳密なアクセス制御を備え、キャッシュ可能な通信プロトコルが好まれる場合に、適しています（一例として、ShopifyやGitHubのようなパブリック向けのeコマースサイト）。アンダーフェッチのリスクとオーバーフェッチのリスクを考慮すると、REST APIは次の目的に最適です。

• よりシンプルなデータ・プロファイルで小規模なアプリを使用する企業
• 複雑なデータ・クエリー要件がない企業
• 顧客ベースの大半が同様の方法でデータと運用を使用している企業

GraphQL APIを使用すると、より柔軟で効率的なデータ取得が可能になり、システムの性能と開発者の使いやすさが向上します。これらの機能により、GraphQLは、フロントエンドの要件が急速に変化する複雑な環境でAPIを構築する場合に特に役立ちます。これには以下が含まれます。

• 帯域幅が限られており、通話と応答を制限したい企業
• データポイントを1つのエンドポイントに統合したいと考えている企業
• 顧客の要望が大きく異なる企業

GraphQLとREST APIはどちらも異なるアプローチを使用していますが、ネットワークの拡張性とサーバーの性能を大幅に向上させる可能性を秘めています。

REST APIとGraphQL APIのどちらか、あるいはその2つを組み合わせてデプロイするかに関係なく、企業はさまざまなプログラミング言語（JavaScript など）による実装や、マイクロサービスやサーバーレス・アーキテクチャーとの統合など、幅広い潜在的なアプリケーションからメリットを得られます。IBM API Connectを使用すると、両方のAPIタイプを使用してITインフラを最適化できます。

IBM API Connectは、APIの作成・管理・保護・ソーシャル化・収益化に加え、データセンターやクラウド環境全体でデジタル・トランスフォーメーションを促進する、フル・ライフサイクルのAPI管理ソリューションです。これは、企業と顧客の双方がデジタル・アプリを強化し、リアルタイムでイノベーションを推進できることを意味します。

API Connectにより、企業はAPI管理の最先端で業務を遂行できるよう支援できます。これは、時間の経過とともに規模が大きく、複雑になり、競争が激化するコンピューティング環境において非常に貴重であることが証明されます。