WebSocket上のReSTは可能ですか？
ReSTfulリクエストを受け取り、XMPPに変換してXMPPサーバーに配信するWebベースのチャットアプリケーションを開発する予定です。
この種のチャットベースのアプリケーションにwebsocketを使用することは、イベント（または応答）を非同期的に配信できるため、有望に見えました。しかし、ブラウザからリクエストを転送するための基礎となるプロトコルとしてwebsocketを使用する場合、これはまだReSTful設計と見なすことができますか？はいの場合、websocketメッセージで表されるURI、動詞（GET、POST ...）、パラメーターはどのように表示されますか？それらをxml/jsonでラップして送信しますか？
また、ReSTfulアーキテクチャは、セッション状態がサーバーに保存されないことを示しています。ただし、この場合、XMPPクライアントセッションが作成されると、このセッションの状態がサーバーに保存されます（ステートレス制約に違反します）
RESTは、プロトコルを課さないアーキテクチャスタイルです。必要に応じて、WebソケットでREST、HTTPでREST、FTPでRESTを実行できます。
HTTPを使用する主な理由は、HTTPを介して任意のコンポーネントまたはプログラミング言語と通信するのが簡単で非常に簡単であり、HTTPが複数の仲介者を持つ分散環境をサポートするためです：プロキシ、ファイアウォール...;そのため、任意のトポロジにサービスを展開でき、誰でもアクセスできます。
私の暴言：RESTlibanであり、Roy Fieldingの論文が真実の源である場合、動詞はセマンティックの一部として認められません。 URIはセマンティックです。さまざまなアクションにさまざまな動詞を使用することは、HTTPを介したRESTの洗練された進化ですが、「真実」の一部ではありません。 Royが論文の第6章で評価した rest over HTTPのシナリオを確認できます 。動詞への言及なし。また、仕様ではなく評価シナリオであることに注意してください。
TLDR;
インターネットを介したリアルタイムの双方向通信が必要で、クライアントがWebブラウザである場合、最良の選択はWebソケットです。次に、Webソケットの上にアプリケーションレベルのプロトコルを実装して、RESTful Webサービスを実装できます。
はい。 SwaggerSocket。 のようなライブラリを使用して、WebSocketでRESTを使用できます。
なぜREST APIをソケットの上に構築したいのですか？REST APIの利点は、ステートレスリクエストのような標準HTTPプロトコルの可能性を活用することです。 GET、DELETEなどのセマンティック動詞は、（クライアント）開発者が簡単に理解できるAPIを構築します。ソケットはHTTP動詞などを提供しないため、ソケット用のある種のHTTPレイヤーを構築することは合理的ではありません。
本当にそのようなものを構築する場合は、HTTPプロトコルを設計図として使用し、HTTPのようなソケットプロトコルを実装することをお勧めします。
XMPPをRESTに変換してからWSでRESTを実行する理由を理解できません。WebSocketのポイントは、XMPPプロトコルを直接ブラウザにより、すべての翻訳の問題が回避されます。
ブラウザからサーバーにXMPPを通信できるJavaScriptライブラリがあります。必要なのは、WSからのXMPPトラフィックをTCPにプロキシしてからXMPPサーバーに直接接続することです。 Kaazingにはgateway があり、これを行う。
オープンソースを使用する場合は、JavaScript XMPPライブラリを作成する必要があります。単純なプロトコル用のJSライブラリを作成する方法を示す例があります。必要なものを見つけて、コンセプトをXMPPプロトコルに拡張するだけです。
要約すると、アーキテクチャは次のようになります。
XMPPクライアントコード<-> XMPP JavaScriptライブラリ<-> WebSocket over http <-> WebSocket to TCP Proxy <-> XMPPサーバー
xMPPクライアントコードとXMPP JavaScriptライブラリがブラウザーで実行され、WSへのTCPプロキシとXMPPサーバーはすべてサーバー側です。
RESTのアーキテクチャスタイルは、主に2つのエンティティを想定しています。クライアントとサーバー。
リアルタイムWebおよびリアクティブシステムの開発に向かって進むと、WebSocketはREST APIの使用を置き換えます。
WSでは、サーバーとクライアントの概念を無視するデータのプッシュとプルが可能です。
STOMP、AMQP、XMPPは、メッセージングプロトコルとして使用できます。
データ自体は、JSONまたはGoogleプロトコルバッファまたはApache Avroである可能性があります。
WebSocketはWebサーバーに関連付けられていませんが、モバイルアプリやデスクトップアプリなどのスタンドアロンアプリで開発することもできます。
Webソケット送信関数にコールバックを追加するプロジェクトを作成しました： https://github.com/ModernEdgeSoftware/WebSocketR2
クライアントがコールバックを実装できるように、メッセージIDが確立されます。タイムアウト後のメッセージの再試行と、接続が切断された場合のサーバーへの再接続を処理します。 その後、動詞とパスを追加することで、ペイロードを必要に応じてRESTfulに構成できます。
これは、ビデオゲームスタジオがUDPを使用して必要な速度を達成する場合と似ていますが、ネットコードは多くのTCPのような信頼性のための機能を実装しています。
私はこの投稿が本当に古いことを理解していますが、「REST_アーキテクチャを選択した場合、リアルタイムコミュニケーションの機能を失うのではないか？」という概念に少し触れたいと思います。
一言で言えば、いいえ。 RESTスタイルの実装の多くは、互換性、発見可能性、およびIoTの影にあるさまざまなデバイスに拡張する手段として、RESTを活用した経験があります。
ただし、RESTに加えてWSを使用することに加えて、ほぼリアルタイムの送信を容易にします。これに本当に役立つ多くの抽象化もあり、APIの構築と、消費アプリケーションのRTコンポーネントの動作方法の決定に集中できます。
REST APIの構築を検討しており、RT用のホイールの再作成を避けたい場合は、Tibco Smart-Sockets、SignalRなどをご覧になることをお勧めします。 _ニーズ。
ゲームのクラウドソリューションと「サーバーエンド/プラットフォームとしてのサービス」（SaaS）を提供しているある会社のブログで、新しいトピックを見つけました。
私はこの会社を宣伝したり、使用したりしていません。そのため、どれだけ良いか悪いかさえ知りません。
しかし、彼らはRESTで読んでください 彼らのブログ