人気のあるクライアント-サーバーアーキテクチャは、通信を二つの部分に分割します：一つは重いタスクを全て引き受け、サービスを提供するもので、サーバーと呼ばれ、もう一つはそれらのサービスを享受するもので、クライアントと呼ばれます。
一般的なクライアント-サーバー通信では、クライアントは単にリソースやサービスを求めるリクエストをサーバーに送信し、サーバーはそのリクエストに対して応答します。
クライアント-サーバー通信において、クライアントとサーバーは、それらが通信を行うプロトコルを理解できるライブラリを持っている必要があります。プロトコルとは、インターネット通信のルールの言語またはセットです。彼らはインターネット上でデータを転送するためのガイドラインに従う転送メカニズムです。
クライアント通信の第二に重要な側面は、クライアントとサーバーが合意できるメッセージ形式です。このメッセージ形式はいくつかのスキーマに基づいており、これらのスキーマに従わない限り、通信は行われません。メッセージ形式は、スキーマに従うXMLに似ているか、特定のキー値ペアを含むJSONファイルです。
この種の通信のもう一つの重要な側面は、リクエストと応答のメカニズムに基づいていることです。つまり、サーバーはクライアントが通信を開始するまで通信しません。RESTとGraphQLでは、これは主に一方向的です。これはgRPCなどの技術で解決される基本的な問題です。
RESTが存在したのはなぜですか？
90年代初頭、SOAPと呼ばれる人気のクライアントサーバプロトコルがあり、XMLメッセージ形式を使用しており、スキーマがハードコーディングされていました。メッセージ形式のスキーマは非常に硬直的でした。自由度の欠如がSOAPの放棄とRESTの出現を引き起こしました。
RESTはJavaScriptの人気が高まることにより、JSONファイル形式の人気が高まったことから生まれました。それは理解が容易で便利でした。メッセージ形式にはキーと値のペアがいくつかありました。
簡単に言うと、RestはHTTPをそのプロトコル（トランスポートメカニズム）としてインターネット上でJSONメッセージを転送するためのガイドラインです。Restを使用すると、スキーマを作成する必要はありません。
RESTとは何ですか？
RESTの出現について話しました。それでは、そのコア技術について深く掘り下げてみましょう。それでは、RESTはRepresentational State Transferの略称であることをお知らせします。Restは標準化されたソフトウェアアーキテクチャスタイルであり、業界で多用されるAPIです。
RESTの人気と広範な使用の理由
- RESTはコミュニケーションアーキテクチャのためにシンプルで標準化されています。Rを利用する際、メッセージやデータのフォーマットについて心配する必要はありません。メッセージ形式について毎回心配する必要はありません。すべてが標準化されており、業界で使用されています。
- RESTは拡張性があります。サービスが大きくなり、より多くの機能が必要になった場合、サーバーのパフォーマンスについて心配することなく、簡単にサーバーを改変できます。また、データを台無しにしない限り、新しい機能を完全に分離して作成できます。
- RESTは状態を持たない。つまり、各リクエストにはサーバーが理解する必要があるデータが含まれている。サーバーのアーキテクチャは、このリクエストの情報を思い出すようになっていますが、RESTアーキテクチャでは、セッション状態はクライアント側に保存されているため、サーバーはより効率的になり、サーバーの負荷はより細かい機能を実行するために小さくなります。
- 最後になりましたが、Restは高性能なアーキテクチャであり、キャッシングをサポートしています。
RESTを使用する場合
レストランのウェブサイトを作成していると想像してください。すべてのメニューがオンラインにあり、食品アイテムは3つのカテゴリに分類されています。
- スターター
- メインコース
- ドリンク
さて、オンラインですべてのドリンクを見たいとします。Restアーキテクチャでは、APIエンドポイントにリソースを簡単かつ一貫して分割できます。もちろん、それらを安全にするために複数の認証を使用できます。
この種のケースでは、ドリンクリソースデータを取得できるエンドポイントにサーバーにGETリクエストを送信します。
同様に、Rest APIですべてのCRUD（作成、読み取り、更新、削除）を実行できるため、データのスーパー転送が必要ない大規模プロジェクトに適しています。リアルタイムでなくても。
データの効率的な転送が重要な要素であるプロジェクトには、Restが最適です。キャッシングは、RESTのもう1つの機能であり、食事予約アプリ、ホテル予約アプリ、ブログサイト、オンラインフォーラムサイトなどの標準アプリケーションに役立ちます。
RESTの制限と問題
RESTは素晴らしいですが、特定の状況では非常に重要ないくつかの欠点があります。それらについて話しましょう。
- 双方向通信の必要性
サーバーがクライアントにデータを送信する必要がある場合はどうでしょうか？サーバーが通信を開始したい場合です。RESTアーキテクチャでは、これは不可能です。もちろん、いくつかのトリックを使うことはできますが、実用的ではありません。 - ライブスコアのウェブサイトを作成するとしましょう。サーバーがクライアントにリクエストを送ってスコアデータを更新する方法をどのように管理しますか？クライアントが10秒ごとにリクエストを送ることができますが、それは全く良い方法ではありません。サーバーを過負荷にし、速度の問題を引き起こす可能性があります。
- RESTアーキテクチャは純粋にリクエストとレスポンスであり、データストリーミング（連続イベント処理）をサポートしていません。
- RESTのステートレス性は、データの状態を決定できないRESTアーキテクチャ上で祝福であると同時に呪いでもあります。
なぜgRPCが存在するのでしょうか？
RESTの最初の問題である双方向通信の必要性に対処するために、サーバーが通信を開始できるようにするWebSocketが発明されましたが、問題はそれがフォーマットを持たないことです。それはただのバイトを送信し、制限がありません。
Websockets自体に問題はありませんでしたが、実際の問題は、あらゆる種類の通信にはプロトコルが必要であり、各プロトコルにはそのプロトコルを使用して通信できるクライアントライブラリが必要であることです。
あなたがRestアーキテクチャで動作するPythonアプリケーションを作成している場合、サーバーと通信できるHTTPクライアントが必要になります。多くの場合、クライアントライブラリは独立した開発者による第三者が作成しています。第三者のライブラリを使用することでセキュリティが脅かされ、アプリケーション全体の通信が第三者に依存することになります。
Webアプリケーションの場合、ブラウザはクライアントライブラリのように機能しますが、Web以外のプロジェクトの場合は第三者のクライアントライブラリが必要です。自分で作成しようと考えているなら、それは簡単ではなく、別のアプリケーションのメンテナンスを負担することになります。
そこで、Restの問題とクライアントライブラリの問題に対処するために、Googleは2015年にgRPCを発明しました。
gRPCの場合、ほとんどの一般的な言語用にGoogleが維持している1つのクライアントライブラリがあります。内部的にはHTTP 2プロトコルを使用し、メッセージ形式としてプロトコルバッファ（protobuf）を使用しています。
クライアントライブラリについて心配する必要はありません。Googleがあなたのためにそしてほぼすべてのプログラミング言語のために維持しています。シングルおよびセントラルなクライアントライブラリは、gRPCの主要な強みの一つです。
gRPCのもう一つの利点は、使用するメッセージ形式です。プロトコルバッファは言語非依存であるため、Pythonでクライアントを作成し、Goでサーバーを作成し、それでも問題なく通信できます。
gRPCは本質的には1つのクライアントライブラリと1つのプロトコルで、どのデバイスでも使用できます。
gRPCとは何ですか？
gRPCはprotobufを使用して通信します。protoファイルをバイナリ形式にシリアル化し、サーバーに送信し、サーバー側で元の形式に逆シリアル化します。これがprotobufを使用する方法です。
gRPCには異なる形式の通信があります。それらをgRPCの機能と考えることができます。
gRPCの特徴
- 単一リクエスト：クライアントがprotoリクエストを送信し、サーバーがそれを受信すると、一定時間待って処理を行い、応答を返す、単純なリクエスト-レスポンス通信です。
- サーバーストリーミング：単一のリクエストを行うと、サーバーから大量のデータが応答として流れてきます。例えば、ビデオをクリックすると、サーバー側からビデオ関連のデータが大量に流れてきます。
- クライアントストリーミング：サーバーストリーミングとは逆で、ここではクライアントが一度に大量のデータをサーバーに送信します。例えば、インターネット上で大きなファイルを共有したり、イメージやビデオをインターネットにアップロードする場合があります。クライアントはサーバー側にデータを継続的に送信します。
- 双方向ストリーミング：このタイプの通信では、クライアントとサーバーが複数のメッセージを送信します。チャットはその良い例です。
これらはgRPCの4つの主要な機能であり、その強力さを生み出しています。
gRPCを使用する場合
gRPCの特徴については、いくつかの使用例を見てきました。チャットアプリケーションを作成したいと想像してみてください。リアルタイムの双方向通信を可能にする高速ストリーミングを実現するために、Rest APIを使用することはありません。その代わりに、gRPCストリームを使用します。これは、速度だけでなく他のいくつかの利点も提供します。
まず、言語に中立的な性質は、サーバーや他のクライアントがどのプログラミング言語で書かれているかに関係なく、メッセージ形式が受け入れられる限り通信が確立できることです。
この機能を使うことで、Android版のチャットアプリはiOS版と通信でき、その逆も可能です。
gRPCの問題点
何事にも問題があります。gRPCも例外ではありません。
- ブラウザサポートの限界:gRPCはHTTP 2を使用しているため、ブラウザからgRPCサービスを直接呼び出すことは難しく、時にはプロキシの設定が必要になります。
- 人間が読めない形式:gRPCがバイナリ形式を使用していることはすべての人に知られていますが、それは人間には読めません。これは、いくつかのケースで不利です。
- 成熟度の欠如:gRPCは2015年に開発されたものであるため、RESTと比較してまだ少し未熟であり、多くのバグや問題が解決される必要があります。
- 学習上の問題:RestとGraphQLはJSONを使用しており、学習が容易です。ほとんどの人はprotobufがまだ新しく複雑なトピックであるため、gRPCの専門家を見つけるのが難しいと考えて、これらに固執しようとします。
RESTとgRPCの比較:
それでは、RESTとgRPCの技術的な違いについて説明します。
メッセージ形式:
RESTで使用されるメッセージ形式はほとんどがJSON（時にはXML形式）で、より読みやすく扱いやすい形式です。RESTではスキーマの心配をする必要はありません。一方、gRPCはプロトコルバッファを使用してデータをシリアル化します。圧縮された形式は軽量で、移動が速くなります。バイナリ形式であるため、データを送信するためにシリアライズおよびデシリアライズします。
HTTP 1.1 vs. HTTP 2:
REST APIは通常、HTTP 1.1をプロトコルとして使用しますが、gRPCはその下でHTTP 2を使用します。REST APIはHTTP 2を使用できますが、リクエスト-レスポンスメカニズムのために制限されています。gRPCはHTTP 2を使用し、クライアント-レスポンスおよび双方向通信の両方をサポートするHTTP 2の利点を活用します。これは、gRPCのパフォーマンスがRESTよりも優れていることを意味する別の側面です。HTTP 1.1のように一方向リクエストを管理し、HTTP 2のように同時に双方向リクエストを管理します。
レイテンシー:
gRPCの低いレイテンシーと通信の高速さは、軽量なマイクロサービスアーキテクチャで構成されるシステムに接続するために有用です。これにより、メッセージ送信効率が向上します。ネットワークのほとんどのケースでは、レイテンシーはRESTが25msを要するのに対し、gRPCのレイテンシーはRESTよりもはるかに短くなります。
ペイロードの制限:
RESTは、送信する出力メッセージに対して最大45MBのペイロード制限がありますが、gRPCには制限がありません。つまり、送信するメッセージはどれだけ重くても構いません。
セキュリティ:
セキュリティの面では、RESTはHTTP 1.1とJSON形式を使用するため、解読とアクセスが容易であり、遅れをとる可能性があります。一方、gRPCはより安全なHTTP 2を使用し、バイナリ形式で解読が難しいprotobufを使用しています。
スピード:
ここでもgRPCが優位で、RESTよりも10倍高速であり、これはHTTP 2をプロトコルとして、protobufをメッセージ形式として使用するためです。
コード生成機能
RESTは組み込みのコード生成機能を提供しておらず、開発者はAPIコードを生成するために第三者アプリケーションが必要ですが、gRPCはprotobufコンパイラにより、複数のプログラミング言語との互換性があるため、ネイティブのコード生成機能を備えています。これは特にマイクロサービスアーキテクチャにとっての利点です。
メンフィスRESTゲートウェイ
様々なユースケースや使いやすさのために、HTTPコールを介してメッセージの生産を可能にするために、メンフィスはRESTベースのリクエスト（=メッセージ）を受け取り、必要なステーションにそれらのメッセージを生産するHTTPゲートウェイを追加しました。
RESTゲートウェイから恩恵を受ける一般的なユースケースは以下の通りです：
- フロントエンドから直接イベントを生産する
- DebeziumをHTTPサーバー経由で接続する
- ArgoCDウェブフック
- PostHog統合
- Fivetran/Rivery/任意のETLプラットフォームからHTTPコールでデータを受信する
メンフィスRESTゲートウェイ + JSONスキーマは、アプリケーションやサービス間のデータ品質を向上させ、健全な通信を保証するための強力な組み合わせとなる可能性があります。
メンフィスは近日中にgRPCもサポートする予定です。
結論
最終的に言いたいのは、RESTが依然として最も使用されているアーキテクチャであり、放棄することは不可能であるということです。RESTには、データストリーミングの欠如、双方向通信のない、遅い速度などの多くの欠点がありますが、日常生活で見られる標準的なアプリケーションに最適です。
一方、gRPCは若くて学習が難しいが、クライアントおよびサーバーサイドの高いデータストリーミング、良好な双方向データストリーミング、高速かつコンパクト、HTTP 2を使用するなど、多くのことを提供しています。その高速なパフォーマンスのため、gRPCはビデオストリーミング、音楽ストリーミング、オンラインゲーム、ファイル共有、チャットアプリなどの高負荷アプリケーションに最適です。