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

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

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

思いやりのある設計によってこれを達成できると思います。もしそうなら、必要なクライアントコードははるかに少なくなります。さらに重要なことは、分割されたインターフェースではなく、サービスへの単一のインターフェースがあることを意味し、最悪の場合、物事がいつレンダリングされるかなどを考えずにこれを接続できることを意味します。

だから、私は知りたい：

1. パフォーマンス以外にすべてのWebサービスの代わりにSignalRを使用しない他の理由はありますか？
2. SignalRのパフォーマンスは、そうするのが理にかなわないということに関して十分ですか？

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

SignalRが従来のWebサービスの代わりに使用するのに十分であれば、これを実現するための実行可能な方法である可能性があります。SignalRには、既に説明したサービスのようにハブを機能させる機能が既に含まれているため、この機能すべてをすぐに反映できる共通ベース（CRUD）サービスを定義できます。そうすれば、ほとんどの場合、サービスへのアクセスを許可することができ、慣習によってアクセスできるものにアクセスするためにコードを書き直す煩わしさを省くことができます。 DOM。

私の編集を読んだ後、私はそれが少し無意味であるように感じるので、私が何を得ているかについて質問があるかどうか私に尋ねてください。基本的に、サービスへのアクセスは可能な限り透過的にする必要があります。

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

• RESTは、APIの通常の呼び出し用であり、クライアントは交換のアクティブなアクターです。クライアントがアドレスのGPS座標を検索する必要がある場合、クライアント 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ソケット接続を開いていることがわかった場合は、それらを使用して単一の呼び出しを行ってから閉じます。または、接続が開いたままで、サーバーがクライアントの要求でのみクライアントに何かを送信している場合は、RESTに切り替えます。

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

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

• .NETでは、それほど難しくはありませんでしたが、それでも、接続が開かれるとすぐにドロップするなど、いくつかの不可解な問題を見つけ出すために数日を費やしました。（これはSignalRの前でした。SignalRを試したことはありません）。また、WCFをWebソケットモードで使用しましたが、これも問題がないわけではありませんでした（ただし、WCFには常に問題が伴うと思います）。

• node.jsではこれは実行可能でしたが、動作するライブラリが見つかるまでライブラリを2回切り替える必要がありました。WebソケットHello Worldを作成しようとして少なくとも1週間は費やしたと思います。

• Pythonで、私は1回試し、2、3日を費やして、放棄しました。うまくいきませんでした。

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

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

私はそれが実際にパフォーマンスなどについてではないと思います。それは標準についてです。RESTは標準であり、IMHOには次の利点があります。

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