さまざまなリソースを管理するための豊富なCRUDエンドポイントのセットを備えたREST APIを公開するシステムがあります。REST APIはフロントエンドでも使用されますAjaxを使用して呼び出しを実行するアプリケーション。
これらの呼び出しの一部を非同期にして、信頼性を高めたいと思います。
明らかな選択は、メッセージブローカー(ActiveMQ、RabbitMQなど)のようです。
これまでメッセージブローカーを使用したことがないので、書き換えなくてもREST APIの前に置く」ことができるかどうか疑問に思っています。
メッセージングシステムを介してのみREST APIにアクセスしたくない:一部のエンドポイントでは、呼び出しは常に同期している必要があり、信頼性はそれほど重要ではありません(主にエラーの場合にユーザーが受け取るため)即時フィードバック)。
このユースケースでは、完全なESBの方が適していますか?
あなたの質問を理解したら、APIエンドポイントをサブスクライバーとして「登録」して、特定のキューに送信されたメッセージを受信できるようにします。
メッセージブローカーがこれを行うように構成できるとは思いません。
たとえば、メッセージブローカーを使用する場合は、プロデューサーとサブスクライバーの両方でJMSAPIを使用する必要があります。
対応するAPI呼び出しを実行するサブスクライバーを実装することが解決策になるかどうかはわかりません。この場合、API呼び出しが実行される前にメッセージがデキューされるため、信頼性が損なわれます。サブスクライバーがAPIの同じプロセスで実行されているかどうかは理にかなっていますが、この場合、ライブラリの代わりにREST APIを使用する必要がある理由は明確ではありません。
IMO @EligioEleuterioFontanaあなたは役割の誤解を持っています:
これらは、異なるサービスを提供する2つの異なるサブシステムです。
さて、彼らの役割を説明しましょうあなたの要件に関して:
私がそれを正しく理解しているなら、私はそれに答えるでしょう:
REST APIは、APIが使用するサブシステムも「隠す」ため、常にクライアントのフロントエンドである必要があります。ユーザーは、サブシステムの選択(たとえば、使用しているDB。キャッシュしていますか?キャッシュしている場合は、何を使用しますか?など)を確認/認識してはなりません。
メッセージブローカーは、要求された作業をオフロードするのに最適です今そして作業を処理する後で。これを行う方法は山ほどありますが(キューやpub/subなど)、ここでのポイントは、クライアントが決して見たり知らなかったりしてはならない決定であるということです。
同期しているApiのいくつかのエンドポイントを持つことができます。承知しました!次に、結果整合性を活用する他のユーザーを用意し(つまり、そのリクエストの場合は、後で処理します(5秒後であっても)、クライアントに「ありがとう!了解しました!やります」という応答を返します。すぐに」)...これはあなたが求めている非同期ワークフローです。
Apiエンドポイントは、シンプルで簡潔で、できればかなり安定している必要があります。うまくいけば、物事を変えるときに舞台裏で行うことは、クライアントから隠されます。これには、メッセージブローカーの使用が含まれます。
とにかく、私がREST Apiとメッセージブローカーをどのように見ているか、そしてそれらが互いにどのように関連しているかについての私の見解です。
Google Cloudサブ/パブを調べる価値があるかもしれませんか? - https://cloud.google.com/pubsub/docs/overview