解説：gRPC vs REST｜その違いは？どちらにする？

gRPCとRESTはともによく利用されるAPIのアーキテクチャです。本文では、gRPCとREST APIの基本情報を紹介した上、両者を完全に比較して解説していこうと思います。本文では、gRPCとREST APIそれぞれのメリットとデメリットなどを了解することができ、どちらにしようかに迷っている場合は、ぜひ本文を見逃しないでください。

gRPCとRESTの基本概念

gRPCとRESTはともによく利用されるAPIのアーキテクチャです。この部分では、gRPCとRESTに関する基本情報を紹介していこうと思います。

REST APIとは

REST（Representational State Transfer）は、Webアーキテクチャのスタイルの1つであり、Web上でリソースを表現し、アクセスするための設計原則の集合体です。RESTは、HTTPプロトコルに基づいており、Webの性質に合わせたシンプルな設計が特徴です。そこで、REST APIとは、Webアプリケーションの機能を外部のクライアントアプリケーションから利用するためのAPIの一種です。REST APIは、HTTPプロトコルを使用して通信を行い、一般的にJSONまたはXML形式でデータをやりとりします。

REST APIでは、リソース（データ）を一意の識別子（URI）で指定し、HTTPメソッド（GET、POST、PUT、DELETEなど）を使用してリソースを操作します。クライアントアプリケーションはHTTPリクエストを送信し、サーバーからのHTTPレスポンスを受け取ります。これにより、Webアプリケーションの機能を外部から利用することができます。

gRPCとは

その一方で、gRPCは、Googleが開発したオープンソースの高性能なリモートプロシージャコール（RPC）フレームワークです。簡単に言うと、gRPCの「g」はGoogleのことを指していて、Googleが開発したRPCのことになります。

gRPCは、Protocol Buffers（protobuf）というシリアライゼーション形式を使用して、クライアントとサーバー間の効率的な通信を可能にします。クライアントとサーバーの間でストリームや双方向通信をサポートすることができます。また、多言語に対応しており、さまざまなプログラミング言語で使用することができます。次の画像のように、gRPCでリモート手続き呼び出しを行う場合、クライアントはgRPC Stubだけが必要で、Proto Requestを通じてgRPC Serverにサービスの呼び出しを開始し、gRPC ServerはProto Response(s)を通じて呼び出し結果をクライアントに返します。

gRPCとRESTの違いを解説

gRPCとRESTとも現在のAPIを実装するために使われるアーキテクチャですが、その違いはなんですか？この部分では、両者の違いについて皆さんに解説しようと思います。

表1：gRPCとRESTの違い

ということで、gRPCとRESTはトレードオフの関係にあり、用途に応じて使い分けることが多いです。高パフォーマンスを要する内部システムではgRPC、外部公開APIではRESTを利用するのが一般的です。

gRPCとRESTの利用シーン

上記の内容からgRPCとRESTとの違いを理解すると、gRPCとRESTが実際の業務中の利用シーンも明らかになれるのでしょう。次は、gRPCとRESTの具体的な利用シーンを皆さんに紹介していこうと思います。

gRPCの利用場面

• マイクロサービス間やサーバークラスター間の内部通信
• リアルタイム性が求められるシステム(金融、モニタリングなど)
• モバイルアプリやIoTデバイスーのサーバー間通信
• OpenAPIとの併用(フロントはREST、バックエンドはgRPC)

RESTの利用場面

• スマートフォンアプリやWebアプリの外部公開API
• クラウドサービスのAPI(AWS、GCPなど)
• 異なる言語やプラットフォーム間の統合
• パブリックAPIやオープンデータの公開

例えば金融取引システムでは取引処理系がgRPCで通信し、参照系のみRESTで公開する、といった形で併用されることも多いです。

gRPCとRESTのメリットとデメリット

gRPCとRESTとメリットとデメリットについては、上記の違い解説に関する内容で多く触れてしまったので、ここでそれぞれのメリットとデメリットをまとめていこうと思います。

gRPCのメリット

前述のように、高パフォーマンスを要する内部システムを構築するためによく使われているので、次のようなメリットがあります。

• パフォーマンスが高い
• プロトコルバッファで効率的なデータ転送
• ストリーミングと二方向通信に強い
• IDLでAPI定義できるので開発が容易
• 自動コード生成が可能

gRPCのデメリット

また、互換性がそんなに高くないといったデメリットもよく指摘されています。

• RESTほど一般的でない
• ブラウザからの直接利用が難しい
• デバッグやトラブルシュートが難しい
• 中間プロキシを経由するとパフォーマンスが低下する

RESTのメリット

RESTなら、一番汎用されているAPIのアーキテクチャとして、様々なメリットをも有しています。

• シンプルで分かりやすいアーキテクチャ
• 多くの言語・プラットフォームで利用可能
• インターネットインフラとの相性が良い
• ブラウザやモバイルアプリ利用に適している

RESTのデメリット

RESTの主なデメリットは次のようになります。

• パフォーマンスが劣る
• ストリーミング等の機能が弱い
• データ構造のレイアウトを自前で設計必要

このように、gRPCとRESTのどちらにするかを決める前に、パフォーマンス要件、クライアント側の形、環境制約、相互運用性、開発コストなどのポイントを考えなければいけません。

ApidogはgRPCとRESTも便利に管理

Apidogは、非常に包括的なAPI管理ツールとして、gRPCとRESTを含む様々なAPI技術をサポートしています。Apidogを使うことで、APIの設計、仕様書生成と共有、APIの単体テスト、テスト自動化及びパフォーマンステストをも利用することができます。また、内蔵のモックサーバーを使うことで、サーバーサイドができていない場合でも、APIの開発プロセスを前に進めることができるので、非常に便利です。

Apidogは、HTTPやgRPCプロトコルにも完璧に対応できます。RESTの場合は、HTTPを選択すれば良いのです。

Apidogは、REST APIを設計することも、テストすることもできます。

また、gRPCを利用する必要がある場合は、ApidogはgRPC APIの作成とテストにも完璧に対応可能です。

まとめ

gRPCとRESTはともにWeb APIを実装するためのアーキテクチャですが、特徴が異なります。gRPCはGoogleが開発し高速なRPCプロトコルを利用しています。一方RESTは汎用的なHTTPベースのアーキテクチャです。

ApidogはgRPCとRESTの両方をフルサポートしたAPI管理ツールとして、gRPC APIもREST APIも、設計からテスト、ドキュメント生成まで一貫して管理できます。gRPCとRESTのどちらを使用する場合でも、両者をうまく組み合わせて利用する場合でも、Apidogがその利用シーンに対応できる高機能なツールになるのでしょう。