RESTまたは多層異種システムのメッセージキュー？

Client application-> Front-end API cloud server->のような3層システム用のREST APIを設計していますuser's home API server (Home)。

Homeはホームデバイスであり、Front-endWebsocketまたは長い投票（これは、RESTに違反している最初の場所です。後でさらに悪化します）を介した接続を維持することになっています。Front-endほとんどの場合、Client要求をHome接続にトンネルし、一部の呼び出し自体を処理します。にHome通知を送信することがありますClient。

Front-endHome基本的に同じAPI を持っています。LAN経由で直接Client接続している可能性がありますHome。この場合、それ自体にHomeいくつかのClientアクションを登録する必要がありFront-endます。

このシステムでのRESTの長所は次のとおりです。

• RESTは人間が読める形式です。
• RESTには、動詞（CRUDなど）、名詞、および応答コードのプロトコルオブジェクトへの明確に定義されたマッピングがあります。
• HTTP上で動作し、可能なすべてのプロキシを渡します。

RESTコントラは次のとおりです。

• リクエストとレスポンスのコミュニケーションスタイルだけでなく、パブリッシュサブスクライブも必要です。
• 3層通信エラーを処理するには、HTTPエラーコードでは不十分な場合があります。必要な接続が壊れていて、あるはずだったことを知るためだけに、非同期呼び出しにFront-end戻る場合があります。202 AcceptedHome503
• Homeにメッセージを送信する必要がありますClient。ClientポーリングするFront-endか、接続を維持する必要があります。

我々は考えているWAMP / アウトバーンを、それがすでにメッセージキューのように見ていることを私を襲ったとき、機能をパブリッシュ/サブスクライブを取得するのWebSocketの上に。

一種のメッセージングキューをトランスポートとして評価する価値はありますか？

メッセージキューの逆のように見えます：

• CRUD動詞とエラーコードをメッセージレベルで自分で定義する必要があります。
• 「メンテナンスコストが高い」と書いてありますが、どういう意味ですか？

これらの考慮事項はどのくらい深刻ですか？

接続性がある場合は、メッセージキューを使用します。ただし、特定の構造と形式のメッセージを送信するには、独自のプロトコルを定義する必要があります（難しいタスクではありません）。

メンテナンスの問題は、通常、クライアントとサーバーが別々に構築されるため、両端が同じメッセージ定義を使用するように注意する必要があることですが、十分に整理されていない場合は、RESTで使用するのと同じXMLを使用してください。サービス。

インターネットを介した接続の問題があり、ポート80とhttpのみで「単方向」通信がある場合は、RESTスタイルのシステムがおそらく最適です。送信してポーリングするか、コールバックデータを取得するためにWebSocketを取得しますが、通常はシステムをクライアント/サーバーとして設計します。接続を取得できる場合は、メッセージングシステムが最適です。

メッセージングシステムにはZeroMQを使用します。フォールトトレラントシナリオを含め、あらゆるシナリオでねじれるように構成できます。しかし、それがhttpで動作するかどうかはわかりません。

アウトバーンはあなたがやろうとしていることにうまく適合しているようです。他にも利用可能なツールがあります。Windows Azureサービスバス（Java、.NET、PHP、Python、NodeJS、Rubyのクライアントフレームワークを備えています）を確認してください。

組み込みの休憩メッセージは便利ですが。アプリケーションが基本的なCRUD操作よりも大きくなることがわかります。たとえば、アプリケーションが銀行システムである場合。の代わりに

Acct 54321のバランスを更新=バランス-20.00 Acct 98765のバランスを更新=バランス+ 20.00

あなたはおそらく単一のメッセージが欲しいでしょう

アカウント54321からアカウント98765に20.00を転送

この障害をRESTではなく今すぐに発見するのが最善です。アプリケーション内でメッセージングのためのよりリッチなモデルを作成する方法について説明しているGreg Youngのイベントセントリックをチェックしてください。