0

私は HTTP のみを処理する必要がある Web バックグラウンドの出身なので、無知を許してください。

クライアントがストンプを使用するメッセージ キューの変更をリッスンするアプリがあります。以前は、クライアントは関連するチャネルをリッスンして、サーバー上の変更について通知するメッセージを受信し、それに応じて自分自身を更新するだけで済みました。シンプルなもの。

クライアントがデータを編集し、それらの変更をサーバーにプッシュできるようにする必要があります。サーバー上のデータはすでに安静なリソースを介して公開されているため、最初は REST にサーバー上のデータを変更するリクエストを送信させることだけを考えていましたが、メッセージングを使用して解決策を見つけることができないかと考え始めました。クライアントが変更を公開できる別のチャネルを開くだけで、サーバーはそのチャネルをサブスクライブして、それに応じて自分自身を更新できます。これを実装するのは明らかに簡単ですが、事前にいくつかの潜在的な落とし穴を指摘してもらいたいです。

私は REST に精通しているので、REST のコンテキストでいくつか質問したいと思います。

  • itemPostQueue、itemPutQueue、itemDeleteQueue などのリソースごとに、キューのグループを REST/CRUD 動詞にマップしますか?
  • GET についてはどうですか? キューを使用してデータを読み取るように要求するにはどうすればよいですか?
  • 問題をキャッチするためにステータス コード メカニズムを置き換えるには、何を使用すればよいでしょうか。または、Stomp でエラー/レシート ヘッダーを使用するだけでよいでしょうか?

回答とアドバイスをいただければ幸いです。

よろしく、

クリス

4

1 に答える 1

0

ここでメッセージングを使用する必要がある理由はわかりませんが、いくつか考えてみましょう。

itemPostQueueのようにネットワーク上でRESTにマップすることもできますが、これはメッセージ指向の人には不自然に感じる可能性があります。セマンティックと配信が保証されたある種のキューが組み込まれている場合は、先に進んでそのメカニズムを使用します。ショッピングカートの例では、メッセージをネットワークに接続し、インフラストラクチャを信頼してサーバーに一度配信することができます。

ここでは、メッセージキューに直接GETのような概念はありません。あなたはそれを一対のメッセージでシミュレートすることができます、私はあなたに要求を送り、あなたは私に応答を送り返します。これはRPCによく似ていますが、さらに分離されています。だから私はあなたにPublishCartリクエストを送信し、後でサーバーはクライアントがリッスンしているチャネルでCartContentsメッセージを送信します。

ステータスコードはより複雑で、通常は2つのキャンプに分類されます。まず、実際のキューライブラリメッセージです。通常のシステムメッセージと同じように処理します。次に、チェーンのどこかで障害が発生したことを示す独自のメッセージをワイヤに送信する場合があります。

メッセージングが行うことの1つは、アプリを大幅に分離することです。何かが起こったことを知っているHTTPとは異なり、キューを使用して、誰かに手紙を送ります。そこに着くかもしれません。郵便配達員はそれを雪の中に落とすかもしれません。犬はそれを食べるかもしれません。一定期間応答がない場合は、他の方法で親戚に連絡するか、類推を取り戻してサーバーに連絡してみてください。キューインフラストラクチャの状態やキューの深さなどの監視は、現在依存している配管であるため、さらに重要になります。

幸運を

于 2009-12-25T16:35:53.043 に答える