はじめに
こんにちは、rendaman0215です。
APIの設計のフェーズでGoogleの記事で以下のような記事を読みました。
とてもわかりやすかったので、良い機会のためまとめてみようと思います。
HTTP通信3つの主要な方法
記事内では、以下の3つが主要な方法として紹介されています。
- REST
- gRPC
- OpenAPI
これが主題になるのですが、gRPCはさておき、そもそもOpenAPIはRESTを記述するフォーマットなので比較対象にならないのでは？？と思いました。
よくよく読み進めてみると、記事内でOpenAPIと言われているものは、RESTに関わらずRPCのような使い方を指しているように見受けられました。
REST
RESTと呼ばれる以下の4つの定義に合致するもの
- 状態管理を行わず、やり取りされる情報のそれ自体で完結して解釈することができる
- 情報を操作する命令の体系があらかじめ定義・共有されている
- すべての情報の汎用的な構文で一意に識別される
- 情報の一部として、別の情報へのリンクを含む
ただし以下のようなシンプルなWebインターフェースとしての意味で使われることも多いです。
RESTはLV3まで定義が存在しており、上記の定義でいうところの情報の一部として、別の情報へのリンクを含むが満たされていないケースが多いです。
- ステートレスであり
- GET、POSTといったHTTPメソッドを利用し
- URL/URIで全てのリソースを一意に識別する
gRPC
gRPCはProtocol Buffersを用いてスキーマを記述しシリアライズします。
シンプルな直感的な方法でリモートプロシージャを定義できます。
そのため、スキーマから自動的にコードを生成してくれるためHTTPを意識せずに開発ができます。
一方でRPC形式では、プロシージャの名前だけでその後どういった動作があるか推測できないことがあるため、API仕様を共有するためにドキュメント化は必須です。
gRPCは、内部でHTTP/2を使用しているため、パフォーマンスに優れています。
しかし、クライアントにHTTP/2の使用を強制できないため外部（ユーザのブラウザや外部サービス）とのやりとりは向いていないこともあります。
OpenAPI
一番慣れ親しんでいる人が多そうですね。
こちらも、エンドポイント名だけでその後どういった動作があるか推測できないことがあるため、API仕様を共有するためにドキュメント化は必須です。
まとめ
どの方法にもメリットデメリットがあるため、用途によって使い分けるのがいいですね。
具体的には以下のポイントでしょうか？
- システム全体が構造化されているか？（REST化するなら必要）
- メンバーのHTTPに関する習熟度が高いか？
- 爆速が求められるか？（速さ重視ならgRPC）
- ブラウザからのアクセスがあるか？（gRPCは不向き）
- サービス間通信か？（早いためgRPC有利）