GRPCとRESTの違いは何ですか?


98

私はこのGRPCの説明を読んでおり、この図は興味深いものです。

ここに画像の説明を入力してください

トランスポート層はどのように機能しますか?ネットワーク経由の場合...なぜRPCと呼ばれるのですか?さらに重要なことに、これはサービス層(http要求を行うメソッドを持つクライアントのクラス)のAPIを実装するRESTとどのように違うのですか?


20
«ネットワーク上にある場合... RPCと呼ばれる理由»— RPCはリモートプロシージャコールであり、「リモート」は完全に「別のホスト上」を意味する場合があるためです。
weirdan 2017

回答:


104

トランスポート層は、TCP / IPの上でHTTP / 2を使用して機能します。これにより、クライアントからサーバーへの単一接続を利用できる低レイテンシ(高速)接続が可能になります(これにより、接続をより効率的に使用し、サーバーリソースをより効率的に使用できます。

HTTP / 2は、双方向接続と非同期接続もサポートしています。そのため、サーバーがクライアントと効率的に通信してメッセージを送信することができます(非同期応答/通知など)。

RESTとgRPCはどちらもクライアント/サーバースタブを生成できます(RESTのSwaggerなどを使用)。

+ ----------- + ---------------- +
| HTTP動詞| CRUD |
+ ----------- + ---------------- +
| GET | 読む|
| PUT | 更新/置換|
| パッチ| 更新/変更|
| 削除| 削除|
+ ----------- + ---------------- +

一方、gRPCでは、同期/非同期、単方向/双方向(ストリーム)など、あらゆる種類の関数呼び出しを定義できます。

gRPCを使用して、クライアントはローカルメソッドを呼び出します。プログラマーにはローカル呼び出しをしているように見えますが、基礎となるレイヤー(自動生成されたクライアントスタブ)がサーバーに呼び出しを送信します。サーバーには、そのメソッドがローカルで呼び出されたように見えます。

gRPCは、基礎となるすべての配管を処理し、プログラミングパラダイムを簡素化します。ただし、一部の専任のREST純粋主義者にとっては、これは過度に複雑に思えるかもしれません。YMMV


2
簡単な質問です。RESTでは、あらゆる種類の関数を呼び出すこともできます。たとえば、Railsでは、REST以外のエンドポイントにGETリクエストを送信して、リソースを取得する以外に何かを行うことができます。RESTfulでないエンドポイントから実際にあらゆる機能を開始できます。RESTでローカルメソッドを呼び出しているように見えるサービスを作成することもできますが、実際には内部ではエンドポイントに対してhttp呼び出しを行っています。したがって、違いはそれほど大きくありません...少なくともトランスポート層では。またはそうですか?
Jwan622 2017

2
REST / RESTfulはHTTPで実行され、gRPCはHTTP / 2で実行されます(WebSocketなど)。Swaggerのコードジェネレーターを使用すると、RESTのクライアントおよびサーバースタブを生成できます。gRPCはプロトファイルを使用してスタブを生成します(古いWSDL / SOAPアプローチとは異なります)。protoファイルはタイプを定義するため、生成されたクライアント/サーバースタブはタイプセーフです。モバイルデバイスでは、gRPC接続は、同じ基本的なHTTP / 2ソケットをモバイルアプリからの他の同時接続と共有できるため、効率的です。
mmccabe

ここでgRPCに素敵なイントロです:medium.com/square-corner-blog/grpc-reaches-1-0-85728518393b ここgRPCのデモです:github.com/mmcc007/go
mmccabe

1
Jwan622とmmccabe:Superglue 2.1ライブラリを使用して、リンゴとオレンジで家を建てることができます。ある時点で、私たちは仕事に適したツールを選択し、常にソフトウェアシステムの複雑さを最小限に抑えるよう努めなければなりません。コードの削除は常にパフォーマンスの最適化であることを忘れないでください;)
Martin Andersson

4
私の見解では、RESTful APIのようなものは、常に古いプロトコルに乗るための「ハック」でした。現代の言語により適したスタックを使用し、クライアントが特に使用している言語にとらわれず、パフォーマンスを劇的に向上させることができるものがある場合、私は最初にバンドワゴンにジャンプします!
マーティンアンダーソン

42

RESTはJSONまたはHTTP / 1.1を必要としません

HTTP / 2経由でprotobufメッセージ(またはその他)を送信するRESTfulサービスを簡単に構築できます

HTTP / 2でJSONを送信するRESTfulサービスを構築できます

HTTP / 1.1を介してprotobufメッセージを送信するRESTfulサービスを構築できます

RESTfulサービスはHTTP / xxの「ハック」ではなく、HTTPの任意のバージョンを成功させた基本的なアーキテクチャプリンシパルに従うサービスです(GETリクエストのキャッシュ機能やPUTリクエストの再生可能性など)。

gRPC、SOAPなど alはハックのようなものです。HTTPを介してRPCスタイルのサービスをトンネリングし、ファイアウォールとミドルボックスの制限を迂回するために、HTTPをハックします。それは必ずしも悪いことではありません。RESTサービスの代わりにRPCスタイルのサービスが必要な場合があります。ミドルボックスを置き換えるのが難しい世界に住んでいる必要があります。

RESTの実際の定義を読む時間がない場合:https : //www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

常にTLDRがあります。ウィキペディアのバージョン:

https://en.wikipedia.org/wiki/Representational_state_transfer

RPCスタイルのサービスが必要な場合は、gRPCが最適です。Web上で生活したい場合、またはRESTfulスタイルのサービスに付属するすべての利点が必要な場合は、RESTfulスタイルのサービスを構築します。RESTfulサービスでJSON形式のデータをシリアライズ/デシリアライズするのが遅すぎる場合は、protobufなどを使用してもまったく問題ありません。

gRPCがバージョン2である場合、それはSOAPのバージョン2です。SOAPのようにひどくないもの。

そして、いいえ、GETリクエストで「関数を呼び出す」だけでは、RESTfulサービスを利用できません。

最後に、RESTfulサービスでprotobufを使用する場合は、コンテンツタイプヘッダーなどを使用して正しく実行してください。これにより、JSONとprotobufの両方を簡単にサポートできます。

私のSOAPボックスから今降りる..;)


RESTfulサービスをgRPCを使用して作成できないことを意味していますか?
Kevin S

1
フィールディングの論文を引用するRTFMはやり過ぎでしたが、それ以外の点では優れた反応を示しました。
rmharrison

4

RESTに対するgRPCの最大の利点は、おじいちゃんHTTP 1.1に対するHTTP / 2のサポートです。次に、HTTP 1.1に対するHTTP / 2の最大の利点は、「HTTP / 2によってサーバーがコンテンツを「プッシュ」できるようになることです...」


1
サーバープッシュはHTTP / 2を必要としません。
ロビングリーン

もっと具体的に教えてもらえますか?これは、HTTP / 2サーバープッシュについて話しているwikiです。en.wikipedia.org
Denis Wang

2
申し訳ありませんが、私はHTTP 2サーバープッシュという意味ではなく、ストリーミング応答を意味していました。由緒あるロングポーリングやWebSocketなど、ストリーミング応答を行う方法は他にもあります。
Robin Green

1
gRPCサーバは、HTTP / 2「プッシュとgRPCクライアント無視HTTP / 2 『プッシュを送信しませんプッシュ『を』HTTP / 2から継承されたのでgRPCの利点は含めるべきではありません。』。
user675693
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.