gRPC と REST の違いはなんですか?
gRPC と REST は API を設計するための 2 つの方法です。API は、2 つのソフトウェアコンポーネントが一連の定義とプロトコルを使用して相互に通信できるようにするメカニズムです。gRPC では、あるコンポーネント (クライアント) が別のソフトウェアコンポーネント (サーバー) の特定の機能のコール (呼び出し) を行います。REST では、関数を呼び出す代わりに、クライアントはサーバー上のデータを要求または更新します。
gRPC とは何ですか?
RPC とは何ですか?
RPC では、クライアントとサーバー間の通信は、クライアント API リクエストがローカル操作であるか、要求が内部サーバーコードであるかのように動作します。
RPC では、クライアントは、常にリモート呼び出しをリスニングしているサーバー上のプロセスにリクエストを送信します。リクエストには、呼び出すサーバー関数と渡すパラメータが含まれています。RPC API は、HTTP、TCP、UDP などのプロトコルを、基盤となるデータ交換メカニズムとして使用します。
gRPC は RPC とどう違うのですか?
gRPC は、いくつかの最適化を加えた従来の RPC を実装するシステムです。例えば、gRPC はデータ送信にプロトコルバッファと HTTP 2 を使用します。
また、データ交換メカニズムをデベロッパーが理解しなくてもすみます。例えば、広く使用されているもう 1 つの RPC API 実装である OpenAPI では、デベロッパーは RPC の概念を HTTP プロトコルに対応付ける必要があります。しかし、gRPC は基盤となる HTTP 通信を抽象化します。これらの最適化により、gRPC は他の RPC 実装よりも高速で実装しやすく、ウェブフレンドリーになっています。
REST とは
REST は、ソフトウェアコンポーネント間でデータを交換するための一連のルールを定義するソフトウェアアーキテクチャアプローチです。ウェブの標準通信プロトコルである HTTP に基づいています。RESTful API は、作成、読み取り、更新、削除操作のための POST、GET、PUT、DELETE などの HTTP 動詞を介してクライアントとサーバー間の通信を管理します。サーバー側リソースは、エンドポイントと呼ばれる URL によって識別されます。
REST は次のように機能します。
- クライアントは、サーバー上のリソースの作成、変更、削除を要求する
- リクエストにはリソースエンドポイントが含まれ、追加のパラメータが含まれる場合もある
- サーバーが応答し、操作が完了するとリソース全体をクライアントに返す
- 応答には JSON 形式のデータとステータスコードが含まれる
REST ガイドラインを使用して構築された API は、RESTful API または REST API と呼ばれます。
なぜ組織は gRPC と REST を使用するのですか?
gRPC と REST は API を開発するための 2 つの異なるアプローチです。
API は、メニューからレストランに料理を注文するのと同様に機能します。どのレストランでも、顧客 (クライアント) は料理のセットが決まっているメニュー (API) から料理を注文できます。これはキッチン (サーバー) に伝えられ、そこでリクエストされた料理を準備して顧客に送ります。顧客はキッチンがどのようにオーダーするかを知る必要はなく、見返りに何を期待できるかを知るだけで済みます。メニュー形式が標準化されるということは、顧客やキッチンがその使い方を知っているということです。
API がなければ、さまざまなアプリケーションやソフトウェアサービスの通信方法について共通の合意が成立しません。2 つの異なるアプリケーションのプログラマーは、毎回互いに話し合い、データ交換を構築する方法を決定する必要があります。
gRPC や REST など、さまざまなタイプの API アーキテクチャが存在します。組織内のさまざまなユースケースには、異なるアーキテクチャの方が適している可能性があるためです。API 設計者は、システム要件に基づいて好みのクライアント/サーバーアーキテクチャを選択する必要があります。
gRPC と REST にはどのような類似点がありますか?
REST と gRPC は、API アーキテクチャのアプローチとして、本質的に似ている点がいくつかあります。
データ交換メカニズム
どちらも、クライアントとサーバーの 2 つのソフトウェアコンポーネントが、共通のルールセットに基づいてデータを通信および交換できるようにします。これらのルールは、各ソフトウェアコンポーネントの内部動作方法に関係なく適用されます。
HTTP ベースの通信
どちらも、ウェブで推奨される効率的な通信プロトコルである HTTP リクエスト/レスポンスメカニズムを介してデータを渡します。ただし、gRPC では、これはデベロッパーには見えませんが、REST ではより明白です。
実装の柔軟性
REST と gRPC の両方をさまざまなプログラミング言語で実装できます。この品質により、どちらもプログラミング環境全体で非常に移植性が高いです。これにより、ほぼユニバーサルなサポートによる最適な相互運用性が実現します。
スケーラブルな分散システムへの適合性
gRPC と REST はどちらも以下を使用します。
- 非同期通信により、クライアントとサーバーは操作を中断することなく通信できる
- ステートレス設計のため、サーバーはクライアントの状態を覚える必要がない
つまり、デベロッパーは gRPC と REST を使用して、多数の同時リクエストを処理する耐障害性のあるシステムを構築できます。複数のクライアントでスケーラブルな分散システムを構築できます。
アーキテクチャの原理: gRPC とREST
REST と gRPC は同様の機能を提供しますが、基盤となるモデルはアーキテクチャが大きく異なります。
コミュニケーションモデル
REST API を使用して、クライアントは 1 つの REST API リクエストをサーバーに送信し、サーバーは返答として 1 つの応答を送信します。クライアントは、操作を続行する前に、サーバーが応答するのを待つ必要があります。このメカニズムはリクエスト/レスポンスモデルであり、単項データ接続 (1 対 1) です。
これとは対照的に、gRPC では、クライアントは 1 つまたは複数の API リクエストをサーバーに送信でき、その結果、サーバーから 1 つまたは複数の応答が返される場合があります。データ接続には、単項 (1 対 1)、サーバーストリーミング (1 対多数)、クライアントストリーミング (多数対 1)、または双方向ストリーミング (多数対多数) があります。このメカニズムはクライアント/レスポンス通信モデルであり、gRPC が HTTP 2 に基づいているため可能です。
サーバー上で呼び出し可能な操作
gRPC API では、呼び出し可能なサーバー操作はサービス (関数またはプロシージャとも呼ばれます) によって定義されます。gRPC クライアントは、アプリケーション内で内部的に関数を呼び出すのと同じように、これらの関数を呼び出します。これはサービス指向設計と呼ばれます。例を示します。
createNewOrder(customer_id, item_id, item_quantity) -> order_id
REST では、URL で定義されたサーバーリソースでクライアントが使用できる HTTP 要求動詞のセットが限られています。クライアントはリソース自体を呼び出します。これはエンティティ指向設計と呼ばれます。エンティティ指向設計は、オブジェクト指向のプログラミング方法によく合います。例を示します。
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id
gRPC API はエンティティ指向のアプローチで設計できますが、これはシステム自体の制約ではありません。
データ交換形式
REST API では、ソフトウェアコンポーネント間で渡されるデータ構造は通常 JSON データ交換形式で表現されます。XML や HTML などの他のデータ形式を渡すこともできます。JSON は読みやすく柔軟性がありますが、シリアル化してプログラミング言語に翻訳する必要があります。
これとは対照的に、gRPC はデフォルトでプロトコルバッファ (Protobuf) 形式を使用しますが、ネイティブの JSON サポートも提供しています。サーバーは、proto 仕様ファイル内のプロトコルバッファインターフェイス記述言語 (IDL) を使用してデータ構造を定義します。次に、gRPC はその構造をバイナリ形式にシリアル化し、指定された任意のプログラミング言語に逆シリアル化します。このメカニズムにより、送信中に圧縮されない JSON を使用するよりも高速になります。プロトコルバッファは、JSON で使用される REST API とは異なり、人間が読める形式ではありません。
その他の主な相違点: gRPC とREST
その他の主な相違点: gRPC とREST
アーキテクチャスタイル以外にも、gRPC と REST には固有の違いがあります。
クライアントとサーバーの結合
REST は緩く結合されているため、クライアントとサーバーは相手の実装について何も知る必要はありません。この疎結合により、API は時間の経過とともに進化しやすくなります。これは、サーバー定義を変更しても、必ずしもクライアントのコードを変更する必要はないためです。
gRPC は緊密に結合されているため、クライアントとサーバーは同じ proto ファイルにアクセスできる必要があります。ファイルを更新するには、サーバーとクライアントの両方で更新が必要です。
コードの生成
gRPC には、クライアント側とサーバー側の選定されたネイティブコード生成機能が組み込まれています。プロトコルバッファコンパイラである protoc により、複数の言語で利用できます。proto ファイルで構造を定義すると、gRPC はクライアント側とサーバー側のコードを生成します。コードの生成により、API 開発の時間が短縮されます。
一方、REST には組み込みのコード生成メカニズムがないため、デベロッパーがこの機能を必要とする場合は追加のサードパーティーツールを使用する必要があります。
双方向ストリーミング
gRPC は双方向のストリーミング通信を提供します。つまり、クライアントとサーバーの両方が 1 つの接続で複数の要求と応答を同時に送受信できます。
REST にはこの機能はありません。
いつ使うべきか: gRPC とREST
REST は現在、ウェブサービスおよびマイクロサービスアーキテクチャで最も一般的な API アーキテクチャです。REST の人気は、そのシンプルな実装とデータ構造のマッピング、可読性、柔軟性によるものです。ウェブサービス開発であれ、内部マイクロサービスであれ、新しいプログラマーが自分のアプリケーション用の RESTful API の開発を始めるのは簡単です。
REST API のユースケースは次のとおりです。
- ウェブベースのアーキテクチャ
- 外部ユーザーが理解しやすい公開 API
- シンプルなデータ通信
gRPC は、REST とは異なり、デベロッパーが分散型データセンター全体のマイクロサービスアーキテクチャ用の高性能 API を作成できるように特別に設計されました。gRPC は、リアルタイムのストリーミングと大量のデータロードを必要とする内部システムに適しています。また、API が時間の経過とともに変化する可能性が低い場合に、複数のプログラミング言語で構成されるマイクロサービスアーキテクチャにも適しています。
gRPC API は次のようなユースケースに適しています。
- 高性能なシステム
- 高いデータロード
- リアルタイムまたはストリーミングアプリケーション
ウェブソフトウェア開発に関するメモ
HTTP は中核的なウェブプロトコルですが、HTTP にはさまざまなバージョンがあり、ウェブブラウザやウェブサーバーでの採用度合いも異なります。
gRPC API は常に HTTP 2 を使用し、REST API は通常 HTTP 1.1 を使用しますが、これは同じ HTTP プロトコルではありません。HTTP 2 は現在では一般的なウェブプロトコルですが、HTTP 1.1 とは異なり、ユニバーサルブラウザをサポートしていません。ブラウザのサポートが限られているため、ウェブアプリケーションをサポートしたいデベロッパーにとって、gRPC はあまり魅力的な選択肢でない場合があります。
相違点の要約: gRPC とREST
| gRPC API |
REST API |
|
| 内容 |
リモートプロシージャコール (RPC) クライアントサーバー通信モデルに基づいて API を作成して使用するシステム。 |
クライアントとサーバー間の構造化されたデータ交換を定義する一連のルール。 |
| 設計アプローチ |
サービス指向設計。クライアントは、サーバーリソースに影響を与える場合と影響しない場合があるサービスまたは機能の実行をサーバーに要求します。 |
エンティティ指向設計。クライアントはサーバーにリソースの作成、共有、または変更を要求します。 |
| コミュニケーションモデル |
単項、1 つのサーバーから多数のクライアント、1 つのクライアントから多数のサーバー、および多数のクライアントから多数のサーバーなどの複数のオプション。 |
単項。1 つのクライアントが 1 つのサーバーと通信します。 |
| 実装 |
動作するには、クライアント側とサーバー側の両方に gRPC ソフトウェアが必要です。 |
クライアント側とサーバー側でさまざまな形式で実装でき、共通のソフトウェアは必要ありません。 |
| データアクセス |
サービス (関数) 呼び出し。 |
リソースを定義する URL 形式の複数のエンドポイント。 |
| 戻りデータ |
プロトコルバッファファイルで定義されているサービスの固定リターンタイプ。 |
サーバーによって定義された固定構造 (通常は JSON) です。 |
| クライアントとサーバーの結合 |
緊密に結合されています。クライアントとサーバーの両方に、データ形式を定義する同じプロトコルバッファファイルが必要です。 |
ゆるく結合されています。クライアントとサーバーは内部の詳細を認識しません。 |
| 自動コード生成 |
ビルトイン機能。 |
サードパーティー製のツールが必要です。 |
| 双方向ストリーミング |
存在します。 |
存在しません。 |
| こんな方に最適 |
高性能またはデータ量の多いマイクロサービスアーキテクチャ。 |
リソースが明確に定義されている単純なデータソース。 |
AWS は gRPC と REST の要件をどのようにサポートできますか?
Amazon Web Services (AWS) には、API 設計者が API ベースの最新のアプリケーションとサービスを構築、実行、管理するのに役立つさまざまなサービスとツールがあります。詳細については、AWS での最新のアプリケーションの構築に関する記事をご覧ください。
API 要件をサポートできる AWS サービスの例を以下に示します。
- Amazon API Gateway を使用すると、デベロッパーは API を大規模に作成、公開、管理できます。API Gateway を使用すると、コンテナ化されたマイクロサービスアーキテクチャとウェブアプリケーション向けに最適化された RESTful API を構築できます。
- Elastic Load Balancing (ELB) はネットワークトラフィックを分散してアプリケーションのスケーラビリティを向上させます。マイクロサービス間または gRPC 対応のクライアントとサービス間で gRPC トラフィックをルーティングおよび負荷分散できます。これにより、お客様のクライアントやサービスの基盤となるインフラストラクチャを変更することなく、アーキテクチャに gRPC トラフィック管理をシームレスに導入できます。
- Amazon Virtual Private Cloud (Amazon VPC) Lattice は、サービス間の通信を一貫して接続、モニタリング、保護するアプリケーションネットワーキングサービスです。コンピューティングリソースとネットワークリソースを自動的にスケールして、高帯域幅の HTTP、HTTPS、gRPC ワークロードをサポートします。
今すぐアカウントを作成して、AWS で gRPC と REST の使用を開始しましょう。
