同じアプリケーション内のRESTful HTTPとwebsocket？

アプリケーションがWebSocketライブフィード用に既に開かれている場合、AJAXサーバーとのその他の通信にそれを使用する必要がありますか？

接続はすでに開かれているので、Request/Responseリアルタイムではなく、リアルタイムのリクエストに使用する必要がありますか？

RESTful HTTPリクエストのほうがデバッグが簡単だと思うので、リクエストを好むブラウザでURLまたはカールを使用して、APIが返すものをテストできます。を開くためにコードを記述する必要はありませんWebSocket。

同じアプリケーションにRESTful HTTP APIあるのWebSocketは奇妙でしょうか？

rest ajax websockets

— マーク
ソース

「APIをテストするためにコードを記述する必要はありません」これについてもう少し説明してもらえますか？APIをテストする必要がないと思う理由は何ですか？

— エリアスヴァンOotegem

間違っていない場合は、Chromeデベロッパーツールを使用すると、

— ウェブソケット

@EliasVanOotegem良い点。申し訳ありませんが、それは明確ではありませんでした。サーバー側のユニットプロジェクトでAPIをテストする必要があります。つまり、APIが返す内容を簡単に確認したい場合は、URLでブラウザを使用できます。Websocketを開くためにコードを記述する必要はありません。質問を更新しました。

— マーク

@maple_shaftそれはいいですが、WebSocketがサーバーに対して開かれているページにいる必要があります。

— マーク

Websocketの中心的な設計目標の1つは、HTTPとWebsocketの両方のプロトコルを同じポートで通信できるようにすることです。これは、クライアントにHTTPアップグレードリクエストでWebsocketハンドシェイクを実行することを明示的に要求することでこれを実現します。このようにして、サーバーは標準のHTTPリクエスト接続と、永続的な双方向二重接続にアップグレードされたHTTPアップグレードリクエストを処理できます。

はい、これは間違いなく有効なユースケースですが、特定のアプリケーションに対してこれを行うべきかどうかはまったく異なります。Websocketは便利であり、サーバーがクライアントに未承諾データを送信する機能を持たなければならないシナリオがある場合に有効です（ライブフィード）。HTTPプロトコルおよびRESTサービスは、データの同期クライアント請求をブロックする場合に役立ちます。

これらの両方がアプリケーションにとって意味のある要件である場合は、必ず両方を使用する必要があります。ただし、サーバーとの唯一の対話がライブフィードベースの場合、RESTサービスは適切ではありません。デバッグの容易さは、設計の設計対象となるシステム品質属性の観点から、重要度がかなり低いと考えられます。

— maple_shaft
ソース

それが私が思っていたことです。リアルタイムのライブフィードにwebsocketを使用するのは理にかなっていますが、CRUD操作についてはどうですか？それらに対して標準のHTTPリクエストを使用することは、私の考えではより理にかなっています。

— マーク

@ Marc、CRUD操作とリアルタイムの懸念（HTTPを使用するWebソケットと他のWebソケットを使用する）を分離するのは奇妙なことではありませんが...サーバーからの応答性が向上するだけでなく、すべての操作に永続的な接続（Websocket）を使用すると、パフォーマンスが向上します。これは本当にあなたのCRUDのニーズに依存しますが、私はCRUD Websocketインターフェースにfromしないでしょう。

— ミスト

賛成！初心者は両方とも同じポートで通信されると述べたので、ライブストリームから株価を取得していて、トラフィックが多いためにストリームが数分間切断された場合、どのようにデータを取得しますか？そのケースに取り組むための戦略があります

— PirateApp