RESTまたは多層異種システムのメッセージキュー？
RESTのような3層システム用のAPIを設計しています：_Client application_-> _Front-end API cloud server_-> user's home API server (Home)。
Homeはホームデバイスであり、Websocketまたはロングポーリングを介して_Front-end_への接続を維持することになっています（これは、RESTに違反している最初の場所です） 。さらに悪化する）。 _Front-end_は主にClientリクエストをHome接続にトンネリングし、一部の呼び出し自体を処理します。 HomeがClientに通知を送信することがあります。
_Front-end_とHomeのAPIは基本的に同じです。 Clientは、LAN経由でHomeに直接接続している可能性があります。この場合、Homeは_Front-end_自体にいくつかのClientアクションを登録する必要があります。
このシステムでのRESTの長所は次のとおりです。
- RESTは人間が読める形式です。
- RESTには、動詞（CRUDなど）、名詞、および応答コードのプロトコルオブジェクトへの明確に定義されたマッピングがあります。
- HTTPを介して動作し、すべての可能なプロキシを渡します。
RESTコントラは次のとおりです。
- リクエストとレスポンスのコミュニケーションスタイルだけでなく、パブリッシュサブスクライブも必要です。
- 3層通信エラーを処理するには、HTTPエラーコードでは不十分な場合があります。 _
Front-end_は、一部の非同期呼び出しに_202 Accepted_を返すだけで、必要なHome接続が壊れており、_503_があったはずであることがわかります。 HomeはClientにメッセージを送信する必要があります。Clientは_Front-end_をポーリングするか、接続を維持する必要があります。
Websocketで [〜＃〜] wamp [〜＃〜] / Autobahn を使用して、パブリッシュ/サブスクライブ機能を取得することを検討しています。キュー。
一種のメッセージングキューをトランスポートとして評価する価値はありますか？
メッセージキューの反対のように見えます：
- CRUD動詞とエラーコードをメッセージレベルで自分で定義する必要があります。
- 「メンテナンスコストが高い」と書いてありますが、どういう意味ですか？
これらの考慮事項はどのくらい深刻ですか？
接続性がある場合は、メッセージキューを使用します。ただし、特定の構造と形式のメッセージを送信するには、独自のプロトコルを定義する必要があります（難しいタスクではありません）。
メンテナンスの問題は、通常、クライアントとサーバーが別々に構築されるため、両端で同じメッセージ定義を使用するように注意する必要があることですが、十分に整理されていない場合は、=で使用するのと同じXMLを使用してくださいRESTサービス。
ポート80とhttpのみで「単一方向」通信を使用し、インターネット経由の接続の問題がある場合は、RESTスタイルのシステムがおそらく最良です。送信してポーリングするか、コールバック用のWebSocketを取得しますデータですが、一般的には、システムをクライアント/サーバーとして設計します。接続を取得できる場合は、メッセージングシステムが最適です。
メッセージングシステムの場合は ZeroMQ を使用します。フォールトトレラントシナリオを含め、あらゆるシナリオでねじれるように構成できます。 httpで動作 かどうかはわかりません。
アウトバーンはあなたがやろうとしていることにうまく適合しているようです。他にも利用可能なツールがあります。 Windows Azure Service Bus を確認してください（Java、.NET、PHP、Python、NodeJS、Rubyのクライアントフレームワークがあります）。
組み込みの休憩メッセージは便利ですが。アプリケーションが基本的なCRUD操作よりも大きくなることがわかります。たとえば、アプリケーションが銀行システムである場合。の代わりに
Acct 54321のバランスを更新=バランス-20.00 Acct 98765のバランスを更新=バランス+ 20.00
あなたはおそらく単一のメッセージが欲しいでしょう
アカウント54321からアカウント98765に20.00を転送
REST後でではなく今すぐに）この障害を発見するのが最善です。アプリケーション内でメッセージングのためのよりリッチなモデルを作成する方法について説明しているGreg Youngの Event Centric を確認してください。