WebアプリケーションでRPCのようなメカニズムの代わりにRESTが一般的に使用されるのはなぜですか？

私はごく最近、少なくとも私が知っている典型的なWebアプリケーションフレームワークと比較して、Webアプリケーションにかなり珍しいカスタムフレームワークを使用している会社で働き始めました。RESTful Webサービスの代わりに、RPCメカニズムを使用してサーバーと通信します。

サーバーとの通信は単純な関数呼び出しのように見えますが、関数はクライアントではなくサーバー上で実行されます。サーバー側には、クライアントが呼び出すことができる機能を定義する方法があります。これをhttpリクエストに変換する方法の詳細は完全に抽象化されています。

私は今これを短い時間だけ使用しましたが、それはかなり便利なようです。しかし、私はこのアプローチのどのような欠点が欠けているのか疑問に思っています。他の誰もが違うやり方をしているように見えますが、これは通常、前者に比べてはるかに高い確率で、私が愚かで素晴らしいことをしているかもしれないというサインです。

RESTはWeb用に設計されており、WebはREST用に設計されています。2つのジャストフィットが一緒になります。Roy Fieldingの2000 PhD論文のアーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計では、RESTという用語を定義および導入しました。WebとRESTの間には重要な相互作用があります。そして彼はそこで学んだことを使って彼の論文でRESTを説明しました。

したがって、WebとRESTが非常にうまく機能する単純な理由は、RESTの定義がWebの仕組みから抽出され、WebがRESTの実装であるためです。

そのため、RESTはWebサービスやWebアプリに適しています。「人間」のWebで動作することがすでに証明されているのと同じことを行い、それらを「マシン」のWebに適用するからです。

RPC の大きな問題（正確な実装に依存）は、基本的に分散コンピューティングの誤りにあります。これについては、このホワイトペーパーでArnon Rotem-Gal-Ozが詳しく説明しています。

1. ネットワークは信頼できます
2. 待ち時間はゼロです
3. 帯域幅は無限です
4. ネットワークは安全です
5. トポロジーは変わらない
6. 管理者が1人います
7. 輸送費はゼロです
8. ネットワークは均質です

これらはすべて、新規参入者が分散システムの作成を開始するときに通常行う仮定です。もちろん、それらはすべて偽です。また、分散システムを作成する際には、それらすべてを考慮する必要があります。

多くのRPC実装の問題は、リモート呼び出しをローカル呼び出しのようにしようとすることです。しかし、彼らは似ていない：

• ローカルコールが失敗することはありません。呼び出したサブルーチンは失敗するかもしれませんが、呼び出し自体は失敗しません–リモート呼び出しはネットワーク上で失われるかもしれません
• ローカルコールは瞬時に行われます。呼び出したサブルーチンは長時間（または無限ループでスタックした場合は永遠に）実行される可能性がありますが、呼び出し自体はまったく時間がかかりません（まあ、呼び出しはせいぜい少数のCPU命令です。インライン化されていますが、非常に高速です）–長時間にわたってリモートコールがネットワークで止まることがあります
• サブルーチンが正常に戻った場合、結果は常に返されます。リモート呼び出しでは、結果がネットワーク上で失われる可能性があります
• 返品は瞬時に行われます–リモートの結果は長時間ネットワーク上を移動できます
• サブルーチンを1回呼び出すと、1回だけ実行されます。リモート呼び出しがネットワーク上で失われたり、重複してリモートルーチンが0〜任意の回数実行される可能性があります。
• 正確に1つの結果が返されます。リモートの結果が失われたり重複したりする可能性があるため、0回以上結果を取得できます
• サブルーチンを2回呼び出すと、2つの結果が得られ、2回目の呼び出しの結果の前に最初の呼び出しの結果が得られます。RPCを使用すると、結果が返されないか、最初の呼び出しのみが返されます、または2番目だけ、または1番目の前の2番目、または最初の1つが失われ、2番目を2回取得する、またはその逆のようになります…
• 私が呼び出した場合はa、その後b、私は結果を取り戻すaと、その後の結果b -これはRPCで、ちょうど前のポイントのより一般的なバージョンであり、あなたはどのような順序で2つの答え0回以上のいずれかを得ることができます

あなたはしますリモート呼び出しのために、上記のすべてに対処する必要があります。あなたのフレームワークが行う場合でも、リモート呼び出しは、あなたは、ローカル電話と区別できないことはできませんあなたが知らないので、どれリモート呼び出しがあります。フレームワークはそれらすべてをあなたに代わって処理しようとするかもしれませんが、問題はフレームワークがあなたのシステムについてあなたと同じくらい多くを知らないことです。時々迷子になっても、実際に問題ではない呼び出しがあるかどうかはわかりません。そのため、フレームワークは非常に防御的でなければならず、遅延と帯域幅の点で高価です。

特にフレームワークは実際にあなたを保護することができないので。CAP定理は、分散システムが同時に、一貫性の利用、およびパーティショントレラントすることはできないと言います。より正確には、パーティションが発生すると、システムは一貫性と可用性の両方を維持し続けることができないため、どちらかを選択する必要があります（一般的な考えに反して、定理では、システムの実行時に3つすべてを使用できないとは言いません）通常、3つすべてを使用できますが、パーティションを作成したら、他の2つのうちの1つを選択する必要があります。PACELC定理は、システムが動作している場合でも、あなたはトレードオフするレイテンシの整合対持っていることを示すことによって、CAP定理を拡張します。

これらはドメイン固有であり、コア設計にとって重要であるため、フレームワークではほとんど保護できない重要なトレードオフです。

アーランの、どのようなアプローチでこれを対比しない仕事を：Erlangで、すべてのメッセージは、彼らがローカルであっても、リモートとして扱われ送ります。これは、上記のすべての問題（およびそれ以上）に対処する準備が常に整っていることを意味します。ただし、ローカルプロセスの場合、これらは少しオーバーヘッドになります。これを支援するために、エラー処理と監視に対処するためのツール、フレームワーク、ライブラリ、パターン、イディオムがたくさんあります。

RPCフレームワークがどのように機能するか、どの言語またはライブラリを使用しているかについては説明していませんが、以前の「ネットワークが存在しないふりをする」タイプに属していると強く疑っています。それらは機能しません。大丈夫処理することにより、ローカルとリモート呼び出しの区別を削除するために、すべてをとしてリモートコール。抽象化を逆にやりすぎる：ネットワークはシステムの一部であり、それを抽象化すると、実際に知る必要があるものを抽象化します。

さて、REST を特に使用する必要があるかどうかにかかわらず、それはまったく別の質問です。上で説明したように、WebはREST用に設計されており、RESTはWeb用に設計されているため、2つは理にかなっていますが、必要に応じて他のアーキテクチャスタイルを使用できます。しかし、あなたの質問の少なくとも一部が、「なぜRPC」についてでした、そしてなぜ私はより正確に、私が説明し、上記の理由を打ち出しタイプ RPC私のは、あなたがトラブルにあなたを着陸さも使用している疑いがあります。

コメントにはすでにいくつかの良いアイデアがありますが、ここで繰り返します。

1. RPCは通常、テクノロジ固有です。
2. 開発者が最も関心を持っているのは、RESTではなくJSONです。

JSONにはいくつかの非常に優れた特性があります。それは単純で、人間が読みやすく、コンピューターが解析しやすく、Javascriptが即座にネイティブに認識します（つまり、Javascriptオブジェクト表記法です）。

RESTのような制約を無視する場合は、リモートプロシージャコールを含め、JSONを使用してほとんど何でもできます。必要なことは、適切なプロトコルを確立することだけです。実際、そのようなプロトコルはすでに存在します：JSON-RPC。

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

RPCとRESTは長所と短所を備えた異なるアプローチにすぎず、両方はコンテキストに応じて価値があります。RESTは、RPCがアクションに重点を置いているため、リソースを操作するために最もよく説明されています。RPCクライアントは、いくつかの方法でサービス実装と緊密に結合されており、クライアントを破壊せずにサービス実装を変更することは非常に困難になります。