2017-02-15 9 views
1

私は、クライアント(他のアプリケーション)が何らかの作業要求をプッシュし、すぐにその作業要求のIDを受け取り、後でその作業要求の結果を受け取るためのopprtunityを与えるWeb APIを設計しています。 この種の相互作用の典型的なアプローチは何ですか? 私はSSE(サーバー送信イベント)とWebScoketテクノロジについて考えて、WebSocket(クライアントはすべての種類のリクエスに対して同じ接続を使用し、すべての種類の応答を受け取る可能性があるため)について考えると、それは私の目標にとっては良い選択ですか?これをどのように拡大縮小することができますか?プッシュベースのAPIデザイン

+0

あなたの質問はあまりにも広すぎますIMO。私はWebアプリの人ではないので、投票には投票しません。 – einpoklum

+0

@einpoklumなぜそうですか?質問は、WebSocket技術が記述されたAPI設計のアプローチに合っているかどうかについてですが、そうでない場合は、より良いアプローチが何であるか疑問に思っています。 – maks

+0

@maks、ソフトウェアデザインの質問は[この1](http://softwareengineering.stackexchange.com)などの別のSOサイトに収まる... StackOverflowコミュニティはより実践的な質問のためのものです。 – Myst

答えて

1

WebSocketテクノロジが記述されたAPIデザインのアプローチに適しているかどうかについての質問ですが、そうでない場合は、より良いアプローチが何か不思議です。それは私の目標にとっては良い選択ですか?

WebSocket接続は、将来不確定な時間に結果を受け取るのに非常に適しており、これを行うための推奨方法です。

クライアントからサーバーへの他のリクエストは、ajax呼び出しでも、WebSocketメッセージとして送信されても​​かまいません。主に、ajax呼び出しとしてリクエストを行う理由があるかどうかによって異なります。確立されたwebSocket接続がすでにある場合は、サーバーとの通信が便利で簡単かつ迅速な方法です。

あなたがやって何の個々の部分を撮影:

(クライアントからサーバーへの)いくつかの作業依頼を押します。

これは、AjaxまたはwebSocketによっても同様に実行できます。既に確立されているwebSocket接続を持つ他の理由がなければ、これは伝統的にAjax呼び出しになります。

は、すぐにその作業要求これは実際にはAjaxを介して、作業要求を送信するので、もしAjaxは、要求/応答プロトコルであるため、Ajaxリクエストを行うには少し楽です

のいくつかのIDを受け取りますそのAjaxリクエストへの応答としてIDを返すことは自明です。 webSocket経由でも可能ですが、webSocketはメッセージングプロトコルに過ぎません。作業要求をサーバーに送信するときは、webSocket経由で送信することができます(前述のように)。そして、サーバは直ちに作業IDを返信することができるが、クライアントは、それらの2つのメッセージが相互に自然な接続を持たないため、以前に送信された要求と戻って来る作業IDを相関させる何らかの方法を開発しなければならない。相関を行うことができる1つの方法は、最初の要求を送信するときにクライアントが一時的なIDまたはハッシュ値を生成するようにすることです(文字通り、タイムスタンプなどのそのクライアントに固有のものである可能性があります)ワークIDを送信するときにIDを返します。これはHTTP/Ajaxのようなリクエスト/レスポンス・プロトコルでは簡単です。

後でその作業要求

HTTPポーリングの結果を受け、WebSocketのか、SSEは、すべて使用することができます。明らかにポーリングは特に効率的ではありません。私はwebSocketがこれに対して完全に動作することを知っており、サーバーがプッシュ方式でクライアントに送信したい他のアイテムのためのオープンコンジットを提供します。私は個人的にそれを経験していませんが、SSEを使ってこの問題を解決することもできます(データをクライアントにプッシュする)。

関連する問題