従来のREST APIの代わりに、SignalR（WebSocket）を完全に使用しない唯一の理由はパフォーマンスですか？

Question

私はいくつかのプロジェクトでSignalRを使用してリアルタイムメッセージング機能を実現しています。確実に動作するようで、使い方を学ぶのはとても簡単です。

少なくとも私にとっての誘惑は、Web APIサービスの開発を中止し、すべてにSignalRを使用することです。

これは思慮深い設計で実現できると思いますが、実現したとしても、必要なクライアントコードははるかに少なくなります。さらに重要なことは、分割されたインターフェースではなくサービスへの単一のインターフェースが存在することを意味し、最悪の場合、whenがレンダリングされることなどを考慮せずにこれを結び付けることができます。

だから、私は知りたい：

パフォーマンス以外のすべてのWebサービスの代わりにSignalRを使用しない理由は他にありますか？
SignalRのパフォーマンスは、意味をなさないことに関して十分か。

node.jsのようなばかげたことなく、サーバー側のオブジェクトとサービスの定義をクライアント側のサービスアクセスコードに変換できることは、長い間私の夢でした。たとえば、興味深いオブジェクトInterestingObjectとサービスCRUDをオブジェクトInterestingObjectServiceに定義すると、サービスへの標準のURLルートを定義できます。たとえば、「/ { serviceName}/{methodName} "-ただし、サービスにアクセスするには、クライアントコードを作成する必要があります。オブジェクトはクライアントからサーバーに渡されて戻されるため、クライアント側のコードでオブジェクトを明示的に定義するhaveを行う実際的な理由はなく、明示的に定義する必要もありません。 CRUD操作を実行するルート。 WinFormsまたは=を作成している場合と同様に、サービスアクセスがクライアントからサーバーに機能し、透過的に戻るという前提でクライアントを作成できるように、これらすべてを標準化する方法があるはずだと思いますJavaアプレットまたはネイティブアプリ、または何がありますか。

SignalRが従来のWebサービスの代わりに使用できるのであれば、これを実現するための実行可能な方法となる可能性があります。 SignalRには、すでに説明したサービスのようにハブを機能させるための機能が含まれているので、この機能のすべてをすぐに利用できるようにするCommon Base（CRUD）サービスを定義できます。次に、サービスへのアクセスを当然のことと見なすことができ、慣例でアクセスできるものにアクセスするためにコードを書き直す煩わしさを省くことができます-さらに重要なことに、これを更新する方法を定義するためにコードを書くのに費やす時間DOM。

私の編集を読んだ後、それは少し無意味であるかもしれないので、私が何を得ているのかについて質問があれば遠慮なく尋ねてください。基本的に、サービスへのアクセスはできる限り透過的にしたいです。

Arseni Mourzenko · Accepted Answer

これら2つのテクノロジーの目的は大きく異なります。

RESTは、APIへの通常の呼び出し用ですクライアントがアクティブなアクターである場合交換の。クライアントがアドレスのGPS座標を見つける必要がある場合、clientはAPIの呼び出しを開始し、座標を受信するか、エラーが発生するまで待機します、またはタイムアウトが経過しました。
Webソケットは、物事を逆に行う必要のあるすべてのものです。たとえば、さまざまなサーバーのログとパフォーマンスをリアルタイムで表示するイントラネットWebサイトを使用している場合、クライアントはパッシブである可能性がありますで、サーバーから新しく公開されたログメッセージまたはパフォーマンスが送信されるまで待機しますメトリック。

違いは明らかです。最初のケースでは、クライアントは特定の情報が必要になる時期を決定します。 2番目のケースでは、クライアントは単に連絡を待つだけで、いつ連絡するかわからない場合があります。

ある意味では、どちらも交換可能です。Webソケットは必要ないときに実装できます（つまり、クライアントはREST呼び出しを行う代わりにWebソケットを介してサーバーを呼び出します）。 Webソケットの代わりにポーリングまたはロングポーリングを使用します（Webソケットが非常に人気になるまで、これが何年もの間成功して使用されていた場合）。

しかし、それらの互換性には代償が伴います。

Webソケットの代わりにポーリングまたはロングポーリングを使用すると、多くの場合、帯域幅を浪費しています。
Webソケットを使用してWeb APIを介して実行できることを行う場合、アクティブなすべてのクライアントからのすべての接続を開いたままにしますが、これは実際には望んでいない場合があります。最大5つのクライアントが同時に存在することが予想される小規模なWebサイトの場合、これは問題ではありません。 Amazon AWSなどのサービスの場合、これを技術的に解決するのは簡単ではありません。

Webソケットが必要ない場合は使用しないでください。アドレスのGPS座標を取得するために、Webソケット接続を開き、呼び出しを行い、応答を待ち、接続を閉じることで何も得られません。RESTは、このようなシナリオのニーズを満たします。

RESTサービスへの呼び出しを通じて繰り返し頻繁に情報を確認している場合、これはWebソケットに移動する必要があることを示す良い兆候かもしれません。同様に、スタックオーバーフローは、 Webソケット。ホームページでF5キーを押すのに時間をかけずに、新しいメッセージがあるかどうかを確認できるためです。
Webソケット接続を開いていることがわかった場合は、それらを使用して1回の呼び出しを行ってから閉じます。または、接続は開いたままですが、サーバーがクライアントの要求によってのみクライアントに何かを送信している場合は、RESTに切り替えます。

また、Webソケットには制限付きサポートがあり、実装が必ずしも容易ではありません。 SignalRを使用すると簡単に実装できますが、他の言語/コンテキスト/環境で実装するのに問題がないという意味ではありません。 RESTを使用すると、それは簡単です。curl呼び出しまたはすべての主流言語で利用できる同様の機能の可能性があります。 Webソケットの場合、[ここにはまだ知らない言語の名前を挿入する]を使用してクライアントを作成するのにどれくらい時間がかかるかわからない。

.NET、Pythonおよびnode.jsのいくつかのプロジェクトでWebソケットを使用しました。

.NETではそれほど難しくはありませんでしたが、それでも、数日かけて、接続が開かれるとすぐに接続が切断されるなど、いくつかの不可解な問題を解決しようとしました。（これはSignalRより前のことです。SignalRを試したことはありません）。私はWebソケットモードでもWCFを使用しましたが、これにも問題はありませんでした（ただし、WCFalwaysには問題があると思います）。
Node.jsではこれは実行可能でしたが、機能するライブラリが見つかるまで、ライブラリを2回切り替える必要がありました。 WebソケットのHello Worldを作成するために少なくとも1週間は費やしたと思います。
Pythonでは、一度試して、2〜3日を費やして、放棄しました。うまくいきませんでした。

これをRESTと比較してください。新しい言語/フレームワークで発生する可能性がある唯一の問題は、POSTファイルを取得するか、非常に大きなバイナリ応答を受信する方法を知ることです。解決策を探すために数時間費やしたことを覚えていますそれでも、特別な場合の数時間は、単純なHello Worldの数日または数週間に比べて何もありません。

dagnelies · Answer

ちょうど私の2セント...

私はそれは本当にパフォーマンスや何かについてではないと思います。それは規格についてです。 RESTは標準であり、IMHOには以下の利点があります。

HTTPリクエストは簡単に使用できます。誰でもすぐにREST APIを使用できます。実際、ブラウザを開いてURLを入力し、データを表示することもできます。どの程度インタラクティブにすることができますか？
（ほぼ）どのプログラミング言語でも使用できます。それは一種の普遍的なインターフェースです。エキゾチックな言語からのSignalRとのインターフェースはそれほど明白ではないようです。
http://petstore.swagger.wordnik.com/ のような、素晴らしいツールのサポートがあります。
デバッグするのに最適な「インターフェース」です。ブラウザで直接着信メッセージと発信メッセージを簡単に監視したり、データを表示したりできます。WebSocketとカスタムライブラリを使用すると、それほど明確ではないため、すべてを明示的にログに記録する必要があります。