ReSTful リクエストを受け取り、それらを XMPP に変換し、XMPP サーバーに配信する Web ベースのチャット アプリケーションを開発することを計画しています。
この種のチャットベースのアプリケーションに WebSocket を使用することは、イベント (または応答) を非同期で配信できるため、有望に見えました。しかし、ブラウザからリクエストを転送するための基本プロトコルとして websocket を使用する場合、これは依然として ReSTful 設計と見なすことができますか? はいの場合、URI、動詞 (GET、POST...)、パラメーターは websocket メッセージでどのように表されますか? それらをxml/jsonでラップして送信しますか?
また、ReSTful アーキテクチャでは、セッション状態がサーバーに保存されないと規定されています。ただし、この場合、XMPP クライアント セッションが作成されると、このセッションの状態がサーバーに保存されます (ステートレス制約に違反します)。
REST は、プロトコルを課さないアーキテクチャ スタイルです。そうです、必要に応じて、REST を Web ソケットで、REST を HTTP で、REST を FTP で実行できます。
HTTP を使用する主な理由は、HTTP を介して任意のコンポーネントまたはプログラミング言語と通信するのが簡単で非常に簡単であることと、HTTP が複数の仲介者 (プロキシ、ファイアウォールなど) を持つ分散環境をサポートしているためです。そのため、サービスを任意のトポロジにデプロイでき、誰でもアクセスできます。
私の怒り: あなたが RESTliban であり、Roy Fielding の論文が真実の情報源である場合、動詞はセマンティックの一部として決して認められません。URI はセマンティックです。さまざまなアクションにさまざまな動詞を使用することは、REST over HTTP の洗練された進化ですが、「真実」の一部ではありません。Roy が評価した REST over HTTPのシナリオは、論文の第 6 章で確認できます。動詞への言及はありません。また、これは仕様ではなく評価シナリオであることに注意してください。
TLDR;
インターネットを介したリアルタイムの双方向通信が必要で、クライアントが Web ブラウザーである場合、最良の選択は Web ソケットです。次に、Web ソケットの上にアプリケーション レベルのプロトコルを実装して、RESTful Web サービスを実装できます。
はい。 SwaggerSocketなどのライブラリを使用して、REST over WebSocket を使用できます。
なぜソケットの上にRESTAPIを構築したいのですか？私見では、REST APIの利点は、ステートレスリクエスト、GET、DELETEなどのセマンティック動詞などの標準的なHTTPプロトコルの可能性を活用して、（クライアント）開発者が簡単に理解できるAPIを構築できることです。ソケットはHTTP動詞などを提供しないため、ソケット用にある種のHTTPレイヤーを構築することになりますが、これは私見では合理的ではありません。
本当にそのようなものを構築する場合は、HTTPプロトコルを青写真として使用し、HTTPのようなソケットプロトコルを実装することをお勧めします。
REST アーキテクチャ スタイルは、主に 2 つのエンティティを想定しています。クライアントとサーバー。
リアルタイム Web とリアクティブ システムの開発に移行するにつれて、REST API の使用に代わって WebSocket が目立つようになるでしょう。
WS ではデータのプッシュとプルが可能であり、サーバーとクライアントの概念を却下します。
STOMP、AMQP、XMPP をメッセージング プロトコルとして使用できます。
データ自体は、おそらく JSON または Google プロトコル バッファ、あるいは Apache Avro です。
WebSockets は Web サーバーに関連付けられていませんが、モバイル アプリやデスクトップ アプリなどのスタンドアロン アプリでも開発できます。
XMPP を REST に変換してから、REST over WS を実行する理由がわかりません。WebSocket のポイントは、XMPP プロトコルをブラウザーに直接取り込んで、すべての変換の問題を回避することです。
ブラウザからサーバーに XMPP を送信できる JavaScript ライブラリがあります。必要なのは、WS からの XMPP トラフィックを TCP にプロキシしてから、直接 XMPP サーバーにプロキシすることだけです。Kaazing には、これを可能にするゲートウェイがあります。
オープン ソースを使用する場合は、JavaScript XMPP ライブラリを作成する必要があります。単純なプロトコル用の JS ライブラリを作成する方法を示す例があります。1 つを見つけて、その概念を XMPP プロトコルに拡張するだけです。
要約すると、アーキテクチャは次のようになります。
XMPP クライアント コード <-> XMPP JavaScript ライブラリ <-> HTTP 経由の WebSocket <-> TCP プロキシへの WebSocket <-> XMPP サーバー
ここで、XMPP クライアント コードと XMPP JavaScript ライブラリはブラウザで実行され、WS から TCP へのプロキシは XMPP サーバーとともにすべてサーバー側にあります。