Rest VS gRPC
APIが初めて登場して以来、APIをよりシンプルで、より強力で、使いやすくするためのアプローチが数多く登場しました。
もしAPIが何かわからない場合は、この記事を読んでください
これはRESTとgRPCのAPISを簡単に比較したものです。
RESTはネットワークアプリケーションを設計するアーキテクチャスタイルです。
プロトコルではなく、Webサービスを作成するための一連の制約と原則です。
RESTのAPIは、以下のコンセプトを考慮して構築されます：
リソース：RESTでは、すべてがリソースであり、物理的なオブジェクト、データの一部、またはサービスになり得ます。
各リソースはユニークなURLで識別されます。
-
HTTP メソッド：
RESTは標準的なHTTPメソッド（GET、POST、PUT、DELETEなど）を使用してリソースに対してCRUD（作成、読み取り、更新、削除）操作を行います。 -
無状態：
RESTfulなAPIは無状態です。つまり、クライアントからサーバーへの各リクエストには、リクエストを理解し実行するために必要なすべての情報が含まれている必要があります。 -
表現：
リソースは、JSONやXMLなど、クライアントのニーズに基づいて複数の表現を持つことができます。
RESTを選ぶ理由？
シンプルさ：RESTは理解し実装が簡単で、Web APIにとって人気の選択肢です。
言語非依存：クライアントとサーバーは異なるプログラミング言語で書かれていても良く、相互運用性を促進します。
キャッシング：RESTはHTTPキャッシングメカニズムを利用してパフォーマンスを向上させます。
成熟度：RESTは長い間存在しており、様々なウェブフレームワークやツールで広くサポートされています。
RESTの欠点
-
過剰取得/不足取得：クライアントが必要とするデータよりも多くまたは少なく受信し、効率に影響を与える可能性があります。
-
遅延：複雑な操作を扱う場合、多くの往復が高い遅延を引き起こす可能性があります。
ではgRPCとは何でしょうか？
gRPCはGoogleが開発した高性能なオープンソースフレームワークで、RPC（リモートプロシージャコール）サービスを定義し、複数のプログラミング言語のクライアントサーバーコードを生成することができます。プロトコルバッファ（protobufs）をデータシリアライゼーションに使用し、HTTP/2をトランスポートに使用しています。
gRPCを選ぶ理由？
-
IDL (インターフェース定義言語)：
gRPCは言語非依存のIDLを使用してサービスやメッセージタイプを定義します。これらの定義は複数の言語でクライアントとサーバーコードを生成するために使用できます。 -
型の強さ：
protobufsによるデータシリアライゼーションは型が強く、データの不一致による実行時エラーの可能性を減らします。 -
HTTP/2：
gRPCはトランスポートにHTTP/2を使用し、マルチプレックス、フロー制御、ヘッダー圧縮などの機能を提供してパフォーマンスを強化します。
gRPCを選ぶ理由？
-
双方向ストリーミング：
gRPCは双方向ストリーミングをサポートし、クライアントとサーバーがメッセージストリームを送信できます。 -
効率：
gRPCはHTTP/2とバイナリシリアライゼーションを使用しており、帯域幅と遅延において非常に効率的です。 -
コード生成：
gRPCは自動的にクライアントとサーバーコードを生成し、人的ミスの可能性を減らします。 -
型の強さ：
protobufsはデータ契約の型とバージョニングを強化する。 -
双方向ストリーミング：
リアルタイムアプリケーションやチャットシステムに最適です。
gRPCの欠点
-
複雑さ：
protobufの定義とコード生成の追加的な複雑さは、一部の開発者にとって難しい場合があります。 -
学習曲線：
gRPCの使用を学ぶには追加の時間と労力が必要になる場合があります。
いつRESTまたはgRPCを選ぶべきか？
これにはプロジェクトの要件と制約に依存しますが
RESTを使う場合：
- シンプルさと素早い開発が必要な場合。
- クライアントとサーバーが異なる言語で実装されている場合。
- 既存のサポートとRESTの成熟度を利用したい場合。
gRPCを使う場合：
- 効率性と低遅延を優先する場合。
- 型の強さとバージョニングの要件がある場合。
- 双方向ストリーミングやリアルタイム通信が不可欠な場合。
- コード生成と保守しやすいAPIから恩恵を受けたい場合。
こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/hasanelsherbiny/rest-vs-grpc-1bj3
