SignalRとWebAPIの2つの組み合わせを使用する理由は？

Question

私は最初から新しいアプリケーションを作成しようとしています。私はSignalRとWebAPIを使用しました。私は違いの多くを知っていると信じていますが、WebSocketを使用して以来SignalRが高速ではありませんか？ WebAPIは、外部フレームワークが再利用できるようにするためには意味があります。 SignalRは、私が必ずしも外部的に使用するつもりはないと私には意味をなさない。私はいくつかの研究をしましたが、あなたがしてはならないと言われているどこにも見つけることができません。私はこれが何らかの意見に基づいていることを認識していますが、なぜSignalRではなく、2つの組み合わせを使用するのですか？

SignalRを使用してそのチャネルの他のクライアントに送信する場合を除いて、発信者に返信するのが間違っていると主張していると思いますか？私にとっては、SignalRはあなたがクライアントに返信するときにWebAPIのように使うことができます。それは間違っていますか？それは、クライアントの呼び出しのためのコードが少なくなっています（2行対6以上、自分が何をしているかによって異なります）。私はデータを操作して呼び出し元に送信しようとしている可能性がありますが、あとですべてのクライアントに送信したり、すべてのクライアントに通知を送信したりしたいと考えています。私は私のwebApiコントローラでsignalR呼び出しを使用するファンではありません。それはsignalRコールがハブ内にあるはずのように感じます。ご協力いただきありがとうございます。

Answer 1

2つの異なる問題をターゲットにしているため、これらを一緒に使用しない理由はありません。 Web-APIは、多くの異なる種類のアプリケーション/デバイスによってWebサービスを容易にターゲットにする手段ですが、SignalRは、クライアントがサーバーをポーリングし続けることなくサーバーがクライアント上でコードの一部を呼び出すことができるように双方向通信を提供します結果のために。

など。クライアントがSignalRの新しいメッセージ（facebook通知など）をサーバーに依頼するのではなく、特定のクライアントに対して新しい通知があることを知っています。クライアントがそれらを要求することなく直接送信できます。

http://www.asp.net/web-api

ASP.NETのWeb APIブラウザや モバイルデバイスなどのクライアントの広い範囲を、到達HTTP サービスを構築することを容易にするフレームワークです。 ASP.NET Web APIは、.NET Frameworkで RESTfulアプリケーションを構築するための理想的なプラットフォームです。

http://www.asp.net/signalr

ASP.NET SignalRは 開発リアルタイム・ウェブの機能を容易にするASP.NET開発者のための新しいライブラリです。 SignalRは、サーバとクライアント間の双方向通信を可能にします。 サーバは が利用可能になるとすぐに接続クライアントにコンテンツをプッシュできるようになりました。 SignalRはWeb Socketsをサポートしており、古いブラウザでは他の 互換の技術に戻っています。 SignalRには、接続の管理（イベントの接続と切断など）のためのAPI、グループ化の接続、および承認が含まれています。

潜在的な問題はSignalRは、クライアント上でJavaScriptコードをターゲットに素晴らしいですが、Web-Apiは、プラットフォームやデバイスのすべての種類との接続を可能にするということです。したがって、WebブラウザをターゲットにするためにSignalRで使用したのと同じテクニックが、ネイティブのAndroid Appで動作するとは限りません。

Answer 2

アプリケーションのニーズに応じて一緒に使用できます。私はあなたがdifference between HTTP and WebSockets protocolsを見ることをお勧めします。WebApiはHTTP（S）、SignalRを主にWebSocket、場合によっては他のものを使用します。彼らにはメリットとデメリットがあります。 SignalRを使用する主なメリットは、上記のようなデュプレックス双方向通信とトラフィックのオーバーヘッドが少ないことです。ブラウザは、リクエストごとにHTTPヘッダーとCookieで数KBのデータをルールとして送信します。

WebSocketを使用する代わりに、ブラウザ、HTTPクライアント、ツール、言語などからRESTfullサービス（HTTP）を使用する方が簡単です。 Google ChromeはWebSocketsトラフィックの監視をサポートしていますが、Microsoft Edgeは非常に貧弱です。

GoogleアナリティクスやMicrosoft Azure Application Insightsなどの多くのツールは、HTTPリクエストのエラーを監視できますが、WebSocketではこれを実行できません。手動で監視を実装する必要があります。実際にWebSocketsのトラフィックは、クライアントからサーバーへの単純なメッセージであり、その逆もあり、追加情報はありません。 SignalRにはいくつかの種類のエラーメッセージフォーマットがあります。

WebSocketはTCP接続を開いているためにさらに多くのサーバーリソースを使用し、WebSocketを使用するWebアプリケーションを拡張するのは難しくなります。たとえば、オンラインユーザーが100,000人いる場合は、100K TCP接続を維持できる必要があることを意味します。 HTTPの場合 - 必要ありません。非常にシンプルなシーンでは、SignalRを何らかのクライアントポーリングと置き換えることができますが、そのアプローチが多くの問題を引き起こす可能性があることに注意してください。

したがって、双方向の通信とトラフィックのオーバーヘッド（通常は1リクエストにつき数KB）を必要としない場合は、WebApiのみを使用してください。

双方向通信が必要な場合は、サーバーからクライアントへのプッシュ通知とWebApiを使用して、クライアントからサーバーへのリクエストを簡単に開発、スケーリング、デバッグしたり、他のソースからAPIを使用したりできます。しかし、あなたはまた、あなたがそれの不利な点で大丈夫か交通量のオーバーヘッドが大きい場合にのみ、SignalRを使用することができます。