gRPCとRESTの比較

インターネットの大きな地図において、アプリケーション・プログラミング・インターフェース（API）は、都市や町、ビーチなどの目的地をつなぐ道路のような役割を果たします。APIは、ソフトウェア・アプリケーション同士がデータや機能、操作をやり取りできるようにする仕組みです。サイバーセキュリティー企業であるImperva社の2023年度レポートによると、インターネット・トラフィックの約71％がAPIコールで構成されており、現代のアプリケーションや企業の運用において、この技術がいかに重要であるかが示唆されています。

ほとんどの開発者にとって、APIの構築方法を理解することが基本的なスキルであるのは当然のことです。しかし、これほど重要なインフラストラクチャーであるだけに、APIにもさまざまな種類があります。

この比喩で言えば、12車線の高速道路と1車線の一般道路のどちらかのほうが「優れている」とは限りません。高速道路は街の景観を壊してしまうかもしれない一方で、一般道路は交通量の多い場所では渋滞を引き起こすことがあります。APIを構築するためのさまざまなアーキテクチャー・スタイル、例えばRESTやgRPCも同じです。それぞれに長所と短所があり、これらを理解することは健全なインフラストラクチャーを作るうえで不可欠です。

表現状態転送（REST）とは、いくつかの設計原則（アーキテクチャー上の制約）の集合です。具体的には、統一インターフェース、クライアントとサーバーの分離、ステートレス性、キャッシュ可能性、多層システム・アーキテクチャー、そしてオプションとしてのコード・オン・デマンドが含まれます。これらの原則に基づいて構築されたAPIは、REST API、またはRESTful APIと呼ばれます。

REST APIは、RESTの原則に従っている限り、さまざまなプログラミング言語やデータ形式を利用できます。これは、APIを構築する最も一般的な方法です。

REST APIは、GET、POST、PUT、DELETEといったHTTPリクエスト（HTTPメソッドとも呼ばれます）を使用して、標準的なデータベース機能を実行します。これらの操作は、リソース・レコードの作成、読み取り、更新、削除に使用され、一般的に「CRUD」と呼ばれます。サーバー側のリソースは、エンドポイントと呼ばれるURLによって識別されます。

例えば、GET要求でレコードの取得、POST要求で新しいレコードの作成、PUT要求でレコードを更新、DELETE要求でレコードの削除を実行します。API呼び出しではすべてのHTTPメソッドを使用できます。適切に設計されたREST APIは、HTTP機能が組み込まれたWebブラウザーで実行されるWebサイトに似ています。

リソース情報は、JavaScript Object Notation（JSON）、HTML、XLT、Python、PHP、プレーンテキストなど、さまざまなメッセージ形式でクライアントに送信できます。JSONは、人間と機械の両方が読み取ることができ、かつプログラミング言語に依存しないため、広く利用されています。

RESTとGraphQLの違いについての詳細はこちら

ブラウザー対応：REST APIはHTTP/1.1と標準的なHTTPメソッド、さらにXMLやJSONといった形式を使用するため、ブラウザーとの互換性があります。

使いやすさ：シンプルで広く普及していることから、RESTは特に初心者にとって理解しやすいと広く見なされています。ツール、チュートリアル、ガイドはGitHubなどに豊富にあります。

柔軟性：REST APIは、クライアントとサーバーの間に緩やかな結合しかないと考えられています。この柔軟性により、変更がよりシンプルかつ迅速に行えるようになります。片方を変更しても、もう一方を変更する必要はありません。

堅牢なエコシステム：REST APIには多数のツールが存在し、幅広いサポートやドキュメントが整備されています。例えば、OpenAPI Specification（OAS）は、REST APIのパラメーターや機能を業界標準として定義しています。OASの最新バージョンであるOAS 3.1には、JSON Schemaとの完全な互換性、SPDX識別子を使用した標準化された識別などが含まれています。

HTTP/1.1への依存：RESTはHTTP/1.1を使用することで、ブラウザーとの高い互換性やヘッダーの一部カスタマイズ性を得られますが、その一方で新しいHTTP/2が持つメリットのいくつかを活用できません。利用できないメリットには双方向ストリーミングが含まれます。RESTがサポートするのは一方向のストリーミングのみで、1つのリクエストに対して1つのレスポンスが返される仕組みです。

低速かつ非効率：HTTP/1.1と同様に、RESTがXMLやJSONといった形式に依存していることには、メリットだけでなくデメリットもあります。これらの形式は人間が読みやすいというメリットがありますが、比較的ファイル・サイズが大きいため、送信が遅くなるという欠点もあります。

追加ツールが必要：RESTのエコシステムは堅牢ではありますが、一部の機能はアーキテクチャーに組み込まれていないため、それを補うためのツールが必要となります。例えばコード生成は、REST向けのプラグインとして利用できますが、それでも追加の手順が必要となり、複雑さが増します。

gRPCは、Remote Procedure Call（RPC）の具体的な実装として、Google社が当初開発したオープンソースのフレームワークです。現在は、Cloud Native Computing Foundation（CNCF）によって管理されています。

gRPCは「Google Remote Procedure Call」の略かもしれませんが、開発者たちは冗談めかして「gRPC Remote Procedure Call」やその他さまざまな意味の可能性もあると主張しています。いずれにせよ、gRPCは他のRPCと同様に、リモート呼び出しをローカル呼び出しのように見せかけ、動作させることを可能にします。

RPCはクライアント／サーバー間のやり取りのモデルとして、API開発によく利用されます。RPCモデルでは、クライアントはスタブと呼ばれる仲介役を介してやり取りを行います。このスタブは、送信用にデータを変換し、サーバーから要求された結果を受け取ると、それをクライアント向けに元の形式へと変換します。RPCフレームワークには、XML-RPCやJSON-RPCをはじめ、さまざまな種類があります。

これらのRPCフレームワークは軽量で比較的扱いやすく、開発の簡素化やネットワーク通信の抽象化といったメリットを提供します。しかし、マイクロサービス・アーキテクチャーや高負荷のデータ処理を行うシステムのような環境では、より高性能なフレームワークが求められることが多く、そのニーズに対応するためにgRPCが開発されました。

gRPCは、Protocol Buffers（Protobuf）と呼ばれるインターフェース定義言語（IDL）を使用し、構造化データをバイナリー形式にシリアライズします。バイナリーはJSONやXMLよりもコンパクトであるため、これによりより大きなペイロードを高速に転送できます。

gRPCはHTTP/2も使用しており、双方向ストリーミングを可能にします。そのため、分散環境（特にリアルタイム通信を必要とするもの）、マイクロサービス・アーキテクチャー、ストリーミング・アプリケーション、そしてモノのインターネット（IoT）デバイスの接続に適したAPI基盤となります。

速度：gRPCはProtobufを利用し、Java、Python、Rubyなど多様な言語のデータをシリアライズおよびデシリアライズして、送信用のバイナリーペイロードに変換します。このコードは軽量であるため、gRPC APIではデータ交換における送信時間とレイテンシーが短縮されます。

コード生成：gRPCには \[protoc] と呼ばれるProtobufコンパイラーが含まれており、ネイティブのコード生成機能を提供します。データ構造を.protoファイルで定義すると、gRPCはクライアント側とサーバー側の両方のコードを生成できます。

HTTP/2対応：gRPCはHTTP/2トランスポート・プロトコルに基づいて動作し、さまざまな種類のストリーミングをサポートします。例えば、クライアント側ストリーミングやサーバー側ストリーミングに加えて、クライアントとサーバーが読み書きストリームで独立してメッセージを送信できる双方向ストリーミングもサポートします。

インターセプター：gRPCはインターセプターと呼ばれるミドルウェアをサポートしており、これによって機能を拡張できます。インターセプターを導入することで、セキュリティー、認証、メトリクス分析などを実装できます。

キャンセルとタイムアウト：gRPCはキャンセルをサポートしており、これはタイムアウトまたはデッドラインとも呼ばれ、指定された時間が経過すると呼び出しがキャンセルされます。

新しさとエコシステム：gRPCにはコード生成などの追加機能が含まれていますが、2016年に初めてリリースされた比較的新しいアーキテクチャーです。その新しさゆえに、従来のアーキテクチャー・スタイルと比べると、ドキュメントやサポートは限定的なものとなっています。

学習曲線の急さ: gRPCはRESTと比べて学習曲線が急であると感じる開発者もいます。バイナリー・データのシリアライゼーションにより効率的な通信が可能になりますが、人間が読み取ることはできません。

ブラウザー非対応：WebブラウザーはgRPCプロトコルをネイティブにサポートしていないため、ブラウザー・ベースのアプリケーションから直接gRPCサービスを呼び出すことはできません。この問題を回避する方法の1つとして、gRPC-Webのようなプロキシーを利用する手段があります。gRPC-Webは、ブラウザーのHTTPとgRPCプロトコルとの間の変換レイヤーとして機能します。

RESTとgRPCには多くの共通点があり、どちらもスケーラブルなシステムの構築に利用されています。類似点は次のとおりです。

クライアント／サーバー・アーキテクチャー：gRPCとRESTはいずれもクライアント／サーバー・アーキテクチャーであり、リクエスト／レスポンス形式によってクライアントとサーバーが通信し、データをやり取りできます。このアーキテクチャーでは、クライアントがリクエストを送信し、サーバーは要求されたデータを返すか、要求された処理を実行して応答します。

プラットフォーム非依存：gRPCとRESTは、異なるオペレーティング・システム上の異なるプラットフォームで構築されたサービス間の通信を可能にします。

ステートレス： RESTとgRPCはいずれもステートレスと見なされており、各リクエストにはそれを完了するために必要なすべての情報が含まれています。サーバーは、以前のリクエストに関する情報を保持する必要がありません。

言語サポート：どちらのアーキテクチャー・スタイルも特定の言語に依存せず、さまざまなプログラミング言語で記述されたアプリケーションから利用できます。この特性により、どちらもプログラミング環境を問わず移植可能です。

HTTPの利用：RESTとgRPCはいずれもHTTPベースの通信に依存しています。ただし、gRPCはHTTP/2を使用する一方、RESTはHTTP/1.1に依存しています。また、gRPCは基盤となるHTTP/2通信プロトコルを抽象化しているのに対し、RESTではHTTP通信の抽象化はそれほど行われていません。

RESTとgRPCの主な違いを理解することで、開発者は構築するAPIにどちらが最適かを判断できます。そうした違いには、次のようなものがあります。

データ形式：REST APIは主にJSONやXMLといったテキストベースの形式を使用します。gRPCはProtobufを使用してデータをバイナリー形式にエンコードします。

通信パターン：RESTは一方向の通信のみをサポートしており、1つのリクエストに対して1つのレスポンスを返します。gRPCはさらに、双方向ストリーミング（クライアントとサーバーが独立してやり取りする）、サーバー・ストリーミング（1回のリクエストで複数のレスポンスが返される）、クライアント・ストリーミング（複数のリクエストが1つのレスポンスにつながる）などもサポートします。

設計パターン：gRPCはサービス指向の設計を採用しており、呼び出し可能なサーバー操作がサービスや関数として定義されます。RESTでは、設計はリソース指向であり、URLで定義されたエンドポイントを介してHTTPメソッドを使用してサーバーのリソースにアクセスします。

結合：gRPCのクライアントとサーバーは密結合しており、両者が同じミドルウェアのprotoファイルにアクセスできる必要があります。一方を変更すると、もう一方も変更する必要があります。RESTは疎結合です。この独立性により、片方のコンポーネントを変更してももう一方には影響しません。

コード生成：gRPCは組み込みのコード生成機能を提供しますが、RESTにはその機能はなく、プラグインで対応する形になります。

実装：RESTは特別なソフトウェアを必要とせず、ブラウザーもサポートしています。gRPCは、サーバー側とクライアント側の両方に特定のソフトウェアが必要です。

RESTがAPI設計の選択肢として広く利用されているのには理由があります。シンプルさ、高い互換性、多用途性により、多くのアプリケーションに最適な選択肢となっています。パブリックAPIの場合、RESTの方がより一般的に利用されており、理解しやすいことが多いため、より妥当な選択となることがよくあります。多くの開発者はRESTにより精通しており、サーバー、API管理ツール、開発ツール、各種テストツールなど、REST専用の大規模なインフラストラクチャーをすでに保有している場合もあります。

RESTは組み込みのキャッシュもサポートしており、頻繁にアクセスされるデータをローカルまたはプロキシー経由で保存できます。キャッシュは速度と効率を大幅に向上させることができますが、同時にさまざまな検証、認証、有効期限に関する情報も含める必要があります。

RESTはHTTP/1.1をサポートし、ブラウザーとの高い互換性を備えていることから、一般的にWebサービスやWeb APIに好まれて利用されています。よりシンプルなデータ通信においては、一般的にgRPCよりもRESTの方が適しています。その緩やかな結合性と低い複雑さにより、システム・アーキテクチャーの拡張性を向上させ、時間の経過とともに環境をより柔軟にすることができます。しかし、この適応性はパフォーマンスの低下という代償を伴います。

gRPCは比較的新しいアーキテクチャーであり、その速度、効率性、組み込みツールが評価され、採用する開発者が増えています。リアルタイムのストリーミング・アプリケーションや、高いパフォーマンスが求められる分散システムにおける大規模データ処理を必要とする複雑なAPIでよく利用されています。RESTよりも複雑ではありますが、HTTP/2とProtobufを活用することで、gRPCはより高いパフォーマンスと拡張性を実現できます。

gRPCはマイクロサービス・アーキテクチャーに適しており、双方向のデータをリアルタイムにストリーミングできるため、アプリケーション内の異なるサービスが同時かつ独立して送受信を行うことができます。また、高速かつコンパクトなデータ送信が可能であり、さらにモバイル・アプリケーションはブラウザーに依存する可能性が低いため、モバイル分野でもgRPCの採用が進んでいます。

gRPCは、コンパクトなペイロード、低レイテンシー、高い処理効率により、低消費電力テクノロジーとの相性が良いことから、IoTデバイスをバックエンドAPIに接続する用途にも最適です。