GraphQL と REST: 知っておくべきことすべて

公開: 2022-09-20

次のプロジェクトの技術スタックに含まれる技術を選ぶのは難しい場合があります。 多くの場合、特に GraphQL API と RESTful API のどちらを選択するかについては、次善の API 設計アーキテクチャを選択することがすべてです。

API を構築するには、SOAP、GRPC、REST、GraphQL の 4 つの重要な方法があります。 API を構築したいときはいつでも、REST と GraphQL に心を狭めることがよくあります。 これは、SOAP と GRPC を使用して API を構築する従来の方法が REST によって変更されたためです。

GraphQL は API を構築するより優れた方法であるため、より優れた REST として広くタグ付けされています。 多くの開発者は、GraphQL が REST に取って代わると考えています。 開発者が REST API を構築する際に直面するいくつかの一般的な課題を GraphQL が解決するのに役立つことを、すでに多くの人が発見しています。

このガイドで、プロジェクトに最適な API 設計アーキテクチャとパターンを選択する方法を学びましょうClick to Tweet

API を構築するこれら 2 つの方法は、まったく異なります。 実際には、これらのテクノロジーは、HTTP 要求を送信して結果を受け取ることによって機能します。 どちらにも長所と短所があります。この記事では、API の開発とスケーリングの方法を変えたこれら 2 つの優れたテクノロジについて詳しく説明します。

ただし、詳細に入る前に、まず GraphQL と RESTful API の意味を調べてみましょう。

GraphQLとは?

GraphQL は API クエリ言語であり、既存のデータを使用してこれらのクエリに応答するためのランタイムです。 また、最も複雑なクエリを処理するための強力なツールも備えています。

GraphQL の中心的な機能は、要求された特定のデータのみを要求して受信する機能です。それ以上のものはありません。 これにより、アプリに合わせて API を簡単にスケーリングできます。

GraphQL の最もエキサイティングな部分は、1 つのエンドポイントですべてのデータを提供できることです。

GraphQL API アーキテクチャ フローチャートのスクリーンショット。
GraphQL API アーキテクチャ。

上の図は、GraphQL アーキテクチャの典型的な表現です。 クライアントはさまざまなデバイスからリクエストを行い、GraphQL はそれらのリクエストを処理して、リクエストされたデータのみを返します。 これにより、RESTful API でのオーバーフェッチとアンダーフェッチの問題がうまく解決されます。

成功したクエリを示す GraphQL Playground のスクリーンショット。
GraphQL プレイグラウンドで成功したクエリ。

上記のサンプルでは、​​GraphQL Playground と、単一のエンドポイントでデータをクエリする方法を示しています。 上部は API エンドポイント、左側は大陸の名前を要求するクエリ、最後に右側は要求したクエリに応答します。

GraphQL は、REST API を使用する際のモバイル アプリ開発者のエクスペリエンスを解決することを主な目的として、Facebook によって作成されました。 2015 年に最初のオープンソース バージョンがリリースされて以来、GraphQL は、テクノロジー ビジネスの大企業によるテクノロジーの採用により、驚異的な成長を遂げました。

GraphQL を使用している企業

以下は、GraphQL をサーバーで積極的に使用している企業とアプリケーションのほんの一部のリストです。

フェイスブック

Facebook は GraphQL を作成し、2012 年からモバイル アプリを強化するためにそれを運用に使用してきました。数十億ドル規模のソーシャル ネットワーク企業は、2015 年に GraphQL 仕様をオープンソース化し、多くの環境やあらゆる規模のチームがアクセスできるようにしました。 .

Facebookのログインページのスクリーンショット。
Facebook は GraphQL を使用しています。

GitHub

GitHub はまた、GitHub GraphQL API を使用して統合を作成し、データを取得し、ワークフローを自動化するための GraphQL API を提供することで、GraphQL の使用を発表します。 GitHub GraphQL API は、GitHub REST API よりも正確で柔軟なクエリを提供します。

GitHub ホームページのスクリーンショット。
GitHub も GraphQL を利用しています。

ピンタレスト

Pinterest も GraphQL のアーリー アダプターです。 写真共有の巨人は、GraphQL の初期の調査と、10 億ドル規模の会社を強化する GraphQL テクノロジをどのように使用するかについて公に議論しました。

Pinterest ホームページのスクリーンショット。
Pinterest も自社のサイトで GraphQL を使用しています。

Intuit、Shopify、Coursera、Airbnb など、他の多くの数十億ドル規模の企業は、GraphQL を使用してアプリケーションを強化しています。 そして、REST に対するこの広範な嗜好は、ますます拡大し続けています。

RESTful API とは?

REST は「Representational State Transfer」の略で、分散型ハイパーメディア システムのソフトウェア アーキテクチャ スタイルです。 サーバーとクライアントの間でリソースを交換するための原則と制約を定義します。

これらの原則が API で守られている場合、その API のアプリケーションは「RESTful」と呼ばれます。 WordPress REST API は、この代表的な例です。

API が Restful API と呼ばれるために満たさなければならない原則と制約の一部を以下に示します。

  • クライアントとサーバーの分離:クライアント (フロントエンド) とサーバー (バックエンド) は完全に分離されており、エンドポイントを介してのみ通信できます。
  • 統一されたインターフェース: インターフェースに表示されるデータは、すべてのデバイスで同一です。
  • ステートレス:サーバーは、現在のリクエストが初めて行われたかどうかを記憶していません。 リクエストが行われるたびに、最初から処理するために必要なすべての情報を含める必要があります。
  • キャッシュ可能性:キャッシュとセッション ストレージは許可されていますが、エンド ユーザーがデータ キャッシュをオプトアウトできるように構成する必要があります。
  • レイヤード システム アーキテクチャ: API は、クライアントもサーバーも、直接通信しているか、仲介者を介して通信しているかを判断できないように設計する必要があります。

以下の図は、基本的な REST アーキテクチャです。 リクエストとレスポンスが通常どのように処理されるかを示します。

RESTful API アーキテクチャのブランチ チャートを示すスクリーンショット。
REST API アーキテクチャ。

GraphQL の利点

以下に、GraphQL を使用する利点をいくつか示します。これは、次の 10 億ドル規模のアプリを構築するのに十分すぎる理由を示しています。

単一の API エンドポイントを介したデータのフェッチ

GraphQL の最大の利点は、単一の API エンドポイントを介して任意またはすべてのデータ ポイントにアクセスできることです。

RESTful API に関する最も一般的な問題の 1 つは、エンドポイントが多すぎて情報にアクセスできないことです。 GraphQL では、エンドポイントが 1 つしかないため、オブジェクトに関するさまざまな情報を取得するために複数のリクエストを送信する必要はありません。

以下の図は、RESTful API と GraphQL を使用してリソースを取得する明確な例を示しています。 GraphQL サーバーのリソースにアクセスするためのエンドポイントは 1 つだけですが、RESTful API のさまざまなリソースにアクセスするには複数の API エンドポイントが必要であることがわかります。

RESTful API での複数のクエリと、それらが GraphQL でどのように処理されるかを示すフローチャート。
REST および GraphQL の API エンドポイント。

オーバーフェッチまたはアンダーフェッチなし

オーバーフェッチまたはアンダーフェッチの問題は、RESTful API の既知の問題です。 これは、クライアントが固定のデータ構造を返すエンドポイントをヒットしてデータをダウンロードするか、予想より多かれ少なかれ取得する場合です。

オーバーフェッチの結果、リクエストは、特定のリクエストで必要とされるよりも多くのデータを受信 (または「フェッチ」) します。 ホームページにユーザー名を表示するために、テーブル内のすべてのユーザーを取得しているとします。 その場合、オーバーフェッチにより、名前だけでなく名前を含む、各ユーザーのすべてのデータが返されます。

アンダーフェッチは比較的まれですが、特定のエンドポイントが要求されたすべての情報を提供できない場合に発生します。 クライアントは、必要に応じて他の情報にアクセスするために追加のリクエストを行う必要があります。

GraphQL は、クライアントが要求した正確なリソースを余分な詳細なしで取得することにより、オーバーフェッチまたはアンダーフェッチの問題を効率的に解決します。

複雑なシステムとマイクロサービスのより良い処理

GraphQL は、統合された複数のシステムの複雑さを統合して隠すことができます。

たとえば、モノリシックなバックエンド アプリケーションからマイクロサービス アーキテクチャに移行したいとします。 GraphQL API は、1 つの GraphQL スキーマにマージすることで、さまざまなマイクロサービス間の通信を処理するのに役立ちます。

これらのスキーマが定義されると、フロントエンドとバックエンドの両方が、スキーマ内のデータがシステム全体で常に同期されることを認識しているため、それ以上変更することなく個別に通信できます。

高速で安全

オーバーフェッチの問題により、クライアントの帯域幅消費が増加し、やがてアプリケーションで遅延が発生する可能性があります。 RESTful API 設計パターンを使用すると、膨大なペイロードから必要な情報を選別するのにより多くの時間がかかります。

オーバーフェッチとアンダーフェッチを回避する GraphQL の機能により、サーバーはセキュアで読みやすく予測可能な形状を返し、API リクエストとレスポンスを高速化します。

REST の利点

GraphQL の人気が高まっているにもかかわらず、REST は依然として最も人気のある API 標準の 1 つです。 その理由を見てみましょう。

  • 学習曲線: RESTful API は、習得と理解が最も簡単です。 これは、他の API に対する主な利点です。
  • シリアル化: REST には、JSON でデータをシリアル化するための柔軟なアプローチと形式が付属しています。
  • キャッシング: REST API は、HTTP プロキシ サーバーとキャッシュを利用して高負荷を管理できます。
  • 複雑なリクエスト: REST API には、さまざまなリクエストに対して個別のエンドポイントがあり、複雑なリクエストを他の API よりも管理しやすくするのに役立ちます。
  • クリーンでシンプル: REST API はエレガントでシンプル、かつクリーンです。 それらは簡単に探索できます。
  • 標準 HTTP プロシージャ: REST は、標準 HTTP プロシージャ コールアウトを使用してデータを取得し、要求を行います。
  • クライアント/サーバー:これは、そのビジネス ロジックがプレゼンテーションから切り離されていることを意味します。 したがって、一方に影響を与えずに一方を変更できます。
  • REST はステートレス:クライアントとサーバーの間で交換されるすべてのメッセージには、メッセージの処理方法を知るために必要なすべてのコンテキストがあります。

GraphQL の欠点

GraphQL と REST の長所について説明したので、GraphQL の欠点のいくつかを調べてみましょう。

  • 難しい学習曲線: GraphQL は REST ほど簡単に習得できません。 GraphQL API の構築で最も困難な部分は、スキーマの設計です。 これには多くの時間とドメイン知識が必要です。
  • ファイルのアップロード: GraphQL にはネイティブのファイル アップロード機能がありません。 これは Base64 エンコーディングを使用して回避できますが、この方法でのエンコーディングとデコーディングのコストは時間と費用がかかる可能性があります。
  • Web キャッシング:キャッシングは、頻繁にアクセスされる情報をサーバーの近くに保持することで、サーバーへの頻繁なトラフィックを減らし、要求と応答プロセスを高速化するのに役立ちます。 GraphQL は、Apollo または Relay クライアントのキャッシング メカニズムに依存する代わりに、HTTP キャッシング メソッドをサポートまたは依存しません。
  • 小さなアプリケーションには不向き: GraphQL は、小さなアプリケーションを構築するための最適な API アーキテクチャではない可能性があります。 アプリが GraphQL によって提供されるより柔軟なクエリを必要としない場合は、REST が最適です。
  • 複雑なクエリの問題:クライアントが望むものを正確に提供する GraphQL の機能は、クエリの伝播の問題にもつながる可能性があります。 クライアントがネストされたクエリを送信しすぎると、間違ったクエリが送信される可能性があり、サーバーにとって非常に時間がかかる可能性があります。 このような要求を満たすには、カスタム エンドポイントで REST を使用することをお勧めします。

REST の欠点

ここで、REST のいくつかの欠点に注意を向けましょう。

ダウンタイムや WordPress の問題に悩まされていませんか? Kinstaは、時間を節約するために設計されたホスティングソリューションです! 私たちの機能をチェックしてください
  • 複数の往復: REST API の最大の問題は、多数のエンドポイントの性質です。 これは、クライアントが完全なアプリケーションのすべてのリソースを取得するには、データを取得するために無数の往復を行う必要があることを意味します。
  • オーバーフェッチとアンダーフェッチ: オーバーフェッチとアンダーフェッチの問題は、RESTful APIS の大きな欠点です。 大量の不要なペイロードをフェッチするため、応答が遅れる可能性があります。
  • 階層: REST API は URI 参照リソースに基づいて構築されているため、単純な階層で自然に編成またはアクセスされないリソースにはあまり適していません。

REST の代わりに GraphQL を使用する理由

次に、今後の API 開発で RESTful API の代わりに GraphQL を検討する理由について説明します。

厳密に型指定されたスキーマ

GraphQL は、強力な型システムを使用して API の機能を定義します。 GraphQL では、スキーマ定義言語 (SDL) を使用して、クライアントがサーバーのデータにアクセスする方法に関するパラメーターを定義します。 クライアントに公開されるすべての API は SDL で書き留められ、RESTful API で見られるデータの不整合の問題が解決されます。

オーバーフェッチまたはアンダーフェッチの禁止

フェッチの過剰または不足の問題は、RESTful API の既知の問題であり、クライアントが要求したよりも多くの情報または少ない情報を返します。 GraphQL は、クライアントが必要な情報を指定するための媒体を提供し、その特定の情報のみを正確に返すことで、この問題を解決します。

複数のエンドポイント

RESTful API の最大の問題の 1 つは、エンドポイントが多すぎて情報にアクセスできないことです。

ID 番号を介して特定のユーザーにアクセスしたいとします。 /users/1のようなエンドポイントが表示されます。 ただし、そのユーザーの写真にアクセスしたい場合は、リクエストを/users/1/photosなどの別のエンドポイントに送信する必要があります。

GraphQL では、単一のエンドポイントがあり、ユーザーに関するさまざまな情報を取得するために複数のリクエストを送信する必要はありません。

GraphQL と REST の対決

最後に、GraphQL API と RESTful API の主な違いについて説明します。 その後、優れた API 設計のいくつかの機能について説明し、各テクノロジがそれらをどのように処理するかを比較します。

パフォーマンス

すべてのリソースにアクセスするための単一のエンドポイントを提供できるため、GraphQL が RESTful API よりも高速に実行されることは間違いありません。 RESTful API は複数のエンドポイントを使用するため、ネットワークの遅延が発生する可能性があります。

クエリの複雑さ

エンドポイントは複数のエンドポイントに分割されていないため、GraphQL クエリは時間の経過とともにますます複雑になる可能性があります。 一方、RESTful API エンドポイントは分離されているため、RESTful API は単純なクエリに制限されています。

人気とコミュニティサポート

GraphQL は、成長を続ける API アーキテクチャ パターンおよびクエリ言語です。 まだ歴史が浅いですが、その採用率とリソース プールは急速に成長しており、自分で学習したい人向けのリソースはすでに豊富にあります。

一方、REST はすでに広範なコミュニティ サポートを誇っており、小規模なマイクロサービスを構築する企業から複雑なソーシャル アプリを構築する企業まで、あらゆる種類の企業で引き続き使用されています。

現在、GraphQL と REST の間の人気コンテストは引き分けです。 どちらのテクノロジも引き続き広く使用され、開発コミュニティによって十分にサポートされています。

学習曲線

GraphQL の学習曲線は急勾配です。 API 開発と一般的なソフトウェア エンジニアリングに関する十分なドメイン知識が必要です。 完全な初心者は、GraphQL を十分に理解して複雑なアプリケーションを構築するのに苦労するでしょう。

逆に、REST は非常に簡単に使い始めることができ、すぐに必要なドメインの知識が少なくて済みます。 RESTful API は、ほとんどの主要なプログラミング言語と一般的なフレームワークにうまく統合されているため、学習が非常に簡単になります。

GraphQL と RESTful API の比較を示すスクリーンショット。
GraphQL と REST。

概要

GraphQL は、SOAP API パターンの問題を解決するために REST が導入されたのと同様に、RESTful API アーキテクチャ パターンの軌跡をたどる新しいテクノロジーです。

GraphQL は、より高速な応答、すべてのクエリに対する単一の API エンドポイント、および一貫したデータ アクセスのための厳密なスキーマを提供します。 これらの理由により、数十億ドル規模の企業が初期段階であっても GraphQL への切り替えを開始しています。 しかし、その限界にもかかわらず、GraphQL の原型である REST は、ステージで強い存在感を維持し続けています。

GraphQL または RESTful API? このガイドでさらに詳しく知る クリックしてツイートする

このガイドでは、GraphQL と RESTful API について知っておく必要のあるすべてのことを調べました。これには、各テクノロジの利点と欠点も含まれており、どちらを好むかを自信を持って決定するのに役立ちます。 また、オーバーフェッチ、アンダーフェッチ、複数のエンドポイントなど、RESTful API の既知の問題と、GraphQL がこれらの問題を解決してアプリのパフォーマンスを向上させる方法についても説明しました。

GraphQL と REST のどちらが次のプロジェクトに適しているかを選択するのに十分な洞察が得られました。 コメント セクションで、選んだ勝者で何を構築するかをお知らせください。