テクノロジーの選択: REST、GraphQL、gRPC の選択方法

REST、GraphQL、gRPC は、最新の Web アプリケーションで最も人気のある 3 つの API 開発テクノロジです。では、テクノロジーを選択する場合、3 つの中からどのように選択すればよいのでしょうか?

この記事では、REST、GraphQL、gRPC の機能と使い方を比較します。

REST - 最も人気のあるテクノロジー

REST

Representational State Transfer (REST)は、最新の Web 開発で最も人気のある API 開発テクノロジです。これはステートレスなデータ転送アーキテクチャです。クライアントのリクエストには、リクエストに必要なすべての詳細が含まれていますが、サーバーはクライアントの状態を保持しません。

REST API は、HTTP ネイティブ キャッシュ ヘッダーをサポートし、HTTP メソッド (POST、GET、PUT、PATCH、および DELETE) を使用してデータを操作します。 REST は学習の敷居が低いため、誰でも簡単に RE

ST を使用できます。

REST は拡張が簡単で信頼性が高く、まだ迷っている場合は、最初に REST を選択できます。

REST の利点

• 標準 HTTP メソッドを安全に使用して CRUD 操作を実装できます。
• REST は非常に成熟しており、完全なドキュメントがあり、簡単に始めることができます。
• キャッシュをサポートします。
• スケーラビリティに優れ、クライアントとサーバーを分離します。
• アプリケーションに簡単に統合できます。

REST の欠点

• 過剰取得と過少取得の問題があります。 オーバーフェッチは、API が実際に必要以上のデータを返すときに発生します。これにより、不必要なネットワーク トラフィック、パフォーマンスの低下、余分な帯域幅の使用が発生する可能性があります。アンダーフェッチは、API が特定のユースケースに必要なデータをすべて返さない場合に発生し、必要な情報をすべて取得するには複数のリクエストが必要になります。これにより、パフォーマンスが低下し、ネットワーク トラフィックが増加し、コード ベースがより複雑になる可能性もあります。
#ステータスを維持できません。
比較的大きなペイロード。
アプリケーションがスケールするにつれて、エンドポイントの数は大幅に増加します。
データベース スキーマやデータ構造を更新するのは簡単ではありません。
REST を選択する場合

特定の要件がない場合は、REST が最適な選択です。開発が初めての場合は、学習曲線が浅いため、REST を使用するのが最適です。さらに、問題の解決策を簡単に見つけることができる巨大なエコシステムがあります。

REST は、キャッシュ サポートを使用してパフォーマンスを向上できるため、より大きなリクエスト量を処理し、帯域幅が制限されている場合に最適です。

一般に、アプリケーションで明示的に GraphQL または gRPC を使用する必要がない場合は、REST を使用します。

GraphQL - クライアント主導の標準

GraphQL は 2015 年に発売されたデータ テクノロジです。クエリ言語です。これにより、開発者は必要なデータを正確に見つけて取得できるようになります。 REST と比較すると、GraphQL はクライアント主導のアプローチであり、必要なデータ、その取得方法、形式をクライアントが決定します。また、クライアントが必要なデータを明示的に指定できるため、オーバーフェッチとアンダーフェッチの問題も解決されます。

GraphQL は、クエリ、ミューテーション、サブスクリプションを使用してデータを操作します。

#Query
• : サーバーにデータをリクエストします。 #Change
: サーバー側のデータを変更します。
• サブスクリプション
: データが更新された場合、サブスクリプションを通じてリアルタイムの更新データを取得します。
• #GitHub は、GraphQL を使用する最大手の企業の 1 つです。 2016 年の REST から GraphQL への切り替えは、GitHub の急速な成長に大きく貢献しました。

GraphQL の利点

• 非常に柔軟で、顧客のニーズに正確に応えることができます。
• 過剰取得や過少取得の問題はありません。
• JavaScript、Java、Python、Ruby、PHP などの主流言語のサポート。
• カスタム データ構造を許可します。
• #単一のクエリに複数のリソースのフィールドを含めることができます。

GraphQL の欠点

• クエリは複雑になる場合があります。
• 組み込みのキャッシュ サポートが不足しています。
• GraphQL の学習は、REST に比べてより困難です。
• ファイルのアップロードはデフォルトではサポートされていません。

GraphQL を選択する場合

クエリにデータベースからの多くのレコードが含まれる場合、GraphQL が最適な選択肢です。 GraphQL を使用すると、オーバーフェッチを排除し、必要なデータのみをクエリして、アプリケーションのパフォーマンスを向上させることができます。さらに、GraphQL は、複数のソースからデータを集約する必要がある状況にも最適です。

クライアントが API をどのように使用するかを完全に理解していない場合は、GraphQL を使用することもできます。 GraphQL を使用する場合、厳密なプロトコルを事前に定義する必要はなく、顧客のフィードバックに基づいて API を段階的に構築できます。

gRPC - パフォーマンス重視のテクノロジー

gRPC は 2016 年に Google によって開始されました。進化したバージョンです。リモート プロシージャ コールが導入されました。これは、最小限のリソースを使用して最大のパフォーマンスを提供する軽量のソリューションです。

gRPC は、プロトコルベースの通信アプローチに従います。通信を開始する前に、クライアントとサーバーの両方が合意する必要があります。 gRPC は、宣言型言語である Protobuf を使用してプロトコルを作成し、選択した言語でクライアントとサーバーに互換性のあるコードを生成します。

gRPC は 4 つの通信方法をサポートします:

• 単項: クライアントはリクエストを送信し、単一の応答を待ちます。
• サーバー ストリーミング: クライアントはリクエストを送信し、複数のレスポンスを受信します。
• クライアント ストリーミング: クライアントは複数のリクエストを送信し、1 つの応答を待ちます。
• 双方向ストリーミング: クライアントは複数のリクエストを送信し、複数の応答を受信します。

gRPC の利点

• オープンソース。開発者は必要に応じて変更できます。
• JavaScript、Java、C、C++、C#、Kotlin、Python、Go、PHP などの複数の言語をサポートします。
• #負荷分散を実行できます。
• デフォルトでは HTTP2 を使用して、REST API と比較して待ち時間を短縮します。
• バイナリ形式を使用してデータをシリアル化します。
• 全二重ストリーミングをサポートします。

gRPC の欠点

• 急な学習曲線: 従来の REST API と比較して、gRPC では、プロトコル バッファーやプロトコル バッファーなどの新しい概念とテクノロジーを習得する必要があります。ストリーム。
• 可読性が低い: バイナリ エンコーディングが使用されているため、gRPC メッセージは人間にとって JSON や XML ほど読みやすく理解するのが簡単ではありません。
• デバッグが難しい: メッセージはバイナリ エンコードされているため、gRPC サービスのデバッグは REST API のデバッグよりも難しい場合があります。
• 小規模アプリケーションには適さない: 少数のサービスと少量のデータしか含まない小規模アプリケーションの場合、gRPC は複雑すぎて不要なオーバーヘッドが追加される可能性があります。
• Web ブラウザはサポートされていません: gRPC は HTTP/2 プロトコルを使用しており、Web ブラウザは現在 HTTP/2 プロトコルのすべての機能をサポートしていないため、Web ブラウザでは使用できません。 .gRPC。

gRPC を選択する場合

1. 効率的なデータ転送が必要: gRPC はバイナリ プロトコルを使用するため、JSON や XML などのテキスト プロトコルよりも高速です、より軽量です。
2. 高い信頼性が必要: HTTP/2 プロトコルに基づく gRPC のトランスポート層は、フロー制御、接続の多重化、ヘッダー圧縮など、信頼性を向上できる多くの機能を提供します。パフォーマンス。
3. 効率的な多言語コミュニケーションの必要性: gRPC は複数のプログラミング言語をサポートし、コードを自動的に生成するツールを提供するため、言語をまたいだコードを手動で記述する必要はありません。
4. 複数のリクエストとレスポンスの種類をサポートする必要がある: gRPC は 4 種類の通信方法 (単項、サーバー ストリーミング、クライアント ストリーミング、双方向ストリーミング) をサポートしているため、最適なものを選択できます。特定のユースケースのコミュニケーション方法。
5. より優れた API 管理の必要性: gRPC は、gRPC-Gateway や Envoy などの強力な API 管理ツールを提供します。これらのツールは、API の検出可能性、ドキュメント化、およびテストを向上させることができます。

gRPC は、さまざまな言語で記述されたサービスと通信できるため、マイクロサービス アーキテクチャで使用してサービス間の通信を処理できます。

結論

REST、GraphQL、gRPC の選択は、特定のシナリオとニーズによって異なります。基本原則は次のように要約されます:

1. REST: REST は、従来の CRUD 操作などの単純な API や Web サービスに適しています。一般に、理解しやすく、使いやすく、サポートとツールの広範なエコシステムがあります。
2. GraphQL: GraphQL は、柔軟性と高度なクエリ機能を必要とするアプリケーションに適しています。アプリケーションで複数のリソースからデータを集約する必要がある場合、またはデータの形式と粒度をより適切に制御する必要がある場合は、GraphQL が良い選択です。
3. gRPC: gRPC は、効率的で信頼性の高いデータ転送を必要とするアプリケーションに適しています。複数のプログラミング言語間の効率的な通信が必要で、より高いパフォーマンスと信頼性を提供したい場合は、gRPC が良い選択です。

ただし、REST、GraphQL、gRPC は相互に排他的な選択肢ではありません。実際の状況では、特定のニーズやシナリオに合わせてそれらを組み合わせることができます。

以上がテクノロジーの選択: REST、GraphQL、gRPC の選択方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。