2
従来のREST APIの代わりにSignalR（websockets）を完全に使用しない唯一の理由はパフォーマンスですか？
私は以前SignalR、いくつかのプロジェクトでリアルタイムのメッセージング機能を実現していました。確実に機能するようで、使い方を学ぶのは非常に簡単です。 少なくとも私にとっての誘惑は、Web APIサービスの開発を放棄し、SignalRすべてに使用することです。 思いやりのある設計によってこれを達成できると思います。もしそうなら、必要なクライアントコードははるかに少なくなります。さらに重要なことは、分割されたインターフェースではなく、サービスへの単一のインターフェースがあることを意味し、最悪の場合、物事がいつレンダリングされるかなどを考えずにこれを接続できることを意味します。 だから、私は知りたい： パフォーマンス以外にすべてのWebサービスの代わりにSignalRを使用しない他の理由はありますか？ SignalRのパフォーマンスは、そうするのが理にかなわないということに関して十分ですか？ 馬鹿げたようなことをせずに、サーバー側のオブジェクトとサービスの定義をクライアント側のサービスアクセスコードに変換できることは、長い間私の夢でしたnode.js。たとえば、興味深いオブジェクトInterestingObjectとそのオブジェクトへのサービスを定義する場合、サービスへCRUDのInterestingObjectService標準のURLルートを定義できます-"/ {serviceName} / {methodName}"-しかし、アクセスするクライアントコードを記述する必要がありますサービス。オブジェクトは、サーバーとバックにクライアントから渡されようとしているので、する実際的な理由はありません持っているがクライアント側のコードでオブジェクトを明示的に定義します。また、CRUD操作を実行するルートを明示的に定義する必要はありません。このすべてを標準化する方法があるはずだと思うので、WinFormsまたはJavaを書いている場合と同じように、サービスへのアクセスがクライアントからサーバーへ、そして透過的に戻るという仮定の下でクライアントを書くことが可能ですアプレットまたはネイティブアプリ、またはあなたが持っているもの。 SignalRが従来のWebサービスの代わりに使用するのに十分であれば、これを実現するための実行可能な方法である可能性があります。SignalRには、既に説明したサービスのようにハブを機能させる機能が既に含まれているため、この機能すべてをすぐに反映できる共通ベース（CRUD）サービスを定義できます。そうすれば、ほとんどの場合、サービスへのアクセスを許可することができ、慣習によってアクセスできるものにアクセスするためにコードを書き直す煩わしさを省くことができます。 DOM。 私の編集を読んだ後、私はそれが少し無意味であるように感じるので、私が何を得ているかについて質問があるかどうか私に尋ねてください。基本的に、サービスへのアクセスは可能な限り透過的にする必要があります。