web-dev-qa-db-ja.com

REST APIとメッセージング

さまざまなリソースを管理するための豊富なCRUDエンドポイントのセットを備えたREST APIを公開するシステムがあります。REST APIはフロントエンドでも使用されますAjaxを使用して呼び出しを実行するアプリケーション。

これらの呼び出しの一部を非同期にして、信頼性を高めたいと思います。

明らかな選択は、メッセージブローカー(ActiveMQ、RabbitMQなど)のようです。

これまでメッセージブローカーを使用したことがないので、書き換えなくてもREST APIの前に置く」ことができるかどうか疑問に思っています。

メッセージングシステムを介してのみREST APIにアクセスしたくない:一部のエンドポイントでは、呼び出しは常に同期している必要があり、信頼性はそれほど重要ではありません(主にエラーの場合にユーザーが受け取るため)即時フィードバック)。

このユースケースでは、完全なESBの方が適していますか?

あなたの質問を理解したら、APIエンドポイントをサブスクライバーとして「登録」して、特定のキューに送信されたメッセージを受信できるようにします。

メッセージブローカーがこれを行うように構成できるとは思いません。

たとえば、メッセージブローカーを使用する場合は、プロデューサーとサブスクライバーの両方でJMSAPIを使用する必要があります。

対応するAPI呼び出しを実行するサブスクライバーを実装することが解決策になるかどうかはわかりません。この場合、API呼び出しが実行される前にメッセージがデキューされるため、信頼性が損なわれます。サブスクライバーがAPIの同じプロセスで実行されているかどうかは理にかなっていますが、この場合、ライブラリの代わりにREST APIを使用する必要がある理由は明確ではありません。

4
Ward Clark

IMO @EligioEleuterioFontanaあなたは役割の誤解を持っています:

  • rESTfulAPI
  • メッセージブローカー

これらは、異なるサービスを提供する2つの異なるサブシステムです。

さて、彼らの役割を説明しましょうあなたの要件に関して

  • システムにデータを取得/プッシュする必要のあるクライアント(デスクトップブラウザ、携帯電話ブラウザ、またはアプリ)があります。 (REST APIの言及からの仮定)。
  • クライアントからのリクエストはHTTP/HTTPSを使用しています(これは要件のREST API部分)です)。
  • プッシュされるデータはすべて、これをより応答性が高く、より速く、信頼性の高いものにする必要があります。

私がそれを正しく理解しているなら、私はそれに答えるでしょう:

  • すべてのクライアントはリクエストをREST APIにプッシュする必要があります。これは単純なCRUD以上のことを行うためです。Apiはセキュリティ(認証と承認)、キャッシング、場合によってはリクエストの調整なども処理します。
  • REST APIは、APIが使用するサブシステムも「隠す」ため、常にクライアントのフロントエンドである必要があります。ユーザーは、サブシステムの選択(たとえば、使用しているDB。キャッシュしていますか?キャッシュしている場合は、何を使用しますか?など)を確認/認識してはなりません。

  • メッセージブローカーは、要求された作業をオフロードするのに最適ですそして作業を処理する後で。これを行う方法は山ほどありますが(キューやpub/subなど)、ここでのポイントは、クライアントが決して見たり知らなかったりしてはならない決定であるということです。

  • MBは、復元力にも優れています(ご指摘のとおり)。何かが失敗した場合、キューのメッセージは「x」時間後に再試行されます...など(いいえ、毒キュー、デッドレターキューなどについては言及しません)。

同期しているApiのいくつかのエンドポイントを持つことができます。承知しました!次に、結果整合性を活用する他のユーザーを用意し(つまり、そのリクエストの場合は、後で処理します(5秒後であっても)、クライアントに「ありがとう!了解しました!やります」という応答を返します。すぐに」)...これはあなたが求めている非同期ワークフローです。

Apiエンドポイントは、シンプルで簡潔で、できればかなり安定している必要があります。うまくいけば、物事を変えるときに舞台裏で行うことは、クライアントから隠されます。これには、メッセージブローカーの使用が含まれます。


とにかく、私がREST Apiとメッセージブローカーをどのように見ているか、そしてそれらが互いにどのように関連しているかについての私の見解です。

3
Pure.Krome

Google Cloudサブ/パブを調べる価値があるかもしれませんか? - https://cloud.google.com/pubsub/docs/overview

1
dwright