はじめに
以前、gRPCについて自分なりに調べてまとめた記事を書きました。
一方で、異なるコンピュータにメソッドの実行を依頼し、その結果を返してもらう、というだけであればRESTで十分ではないかという疑問も生まれました。 そのため、REST APIとの違いに着目して追加で調査を行いました。
REST APIとは
gRPCとの比較をする前に、REST APIがどのようなものかざっくりと確認します。
まず、RESTはAPIの動作に一定の条件を求めるソフトウェアアーキテクチャです。
RESTful Webサービスを読む限り、RESTとは「（一般的にURIの形式で表現される）リソースと（GET、POST、PUT、DELETE等の）メソッドの組み合わせでリクエストを表現することができるという特徴を持つアーキテクチャ」で、このアーキテクチャを適用して作ったAPIがREST APIと理解できそうです。
また、Web を支える技術曰く、通信方式はリクエスト/レスポンス型のプロトコルで、クライアントはリクエスト後レスポンスが返却されるまで待機する、という流れのようです。
REST APIとの比較
ちょうど以下に比較の表があったので、かいつまんで取り上げてみようと思います。
| 項目 | REST | gRPC |
|---|---|---|
| 流通度合い | 古くから利用される形式 | 比較的新しいが注目を集めている |
| 通信方式 | リクエスト・レスポンス型の単方向通信 | バイナリ方式での双方向通信 |
| 結合度合い | リソースとメソッド（とAPIごとの制約）が分かれば利用できる | クライアント・サーバーの両方にgRPCのソフトウェアが必要、かつクライアントとサーバーの両方にデータ形式を定義する同一のファイルが必要 |
| パフォーマンス | gRPCと比較すると低速 | 高速 |
| コード生成機能 | サードパーティ製ツールでの提供あり | ビルトイン機能として備わっている |
ざっくりみた感じ、RESTはgRPCよりクライアントとサーバーが比較的独立した形で構築できる比較的一般に広まっているシンプルな方式、gRPCはクライアント・サーバー間で連携が必要である一方、RESTと比べると高速かつできるだけ早く構築を進められるようにコード自動生成機能もビルトインで持っている、といった印象です。
どのようなケースでgRPCを使うべきか
gRPCではクライアントとサーバーの連携が必要になる以上、広く使用されることを想定するAPIには向いていなさそうな印象です。
一方で、緊密な連携が比較的しやすい社内APIで、パフォーマンスが重視されるケースでは、選択肢として挙がってきそうです。
まとめ
gRPCについて概要を理解した上で、RESTとの比較を行うことでgRPCの使いどころをなんとなく把握できました。
自分しか使わないAPIといったケースでもgRPCは問題なく使えそうなので、自分用のREST APIを作る機会があれば、合わせてgRPCでも作ってみて比較等もしてみたいですね。
