回答:
RESTを破棄すると、単なるHATEOASをはるかに超えて失われます。マイクロサービスが公開されている場合（少なくとも1日公開される傾向がある場合）、RESTとSOAP以外を使用すると問題が発生します。
一部の開発者はAMQPを使用したことがないため、
AMQPを使用した人もいますが、多くの場合、RESTとSOAPにはるかに精通しています。
一部の言語のAMQPライブラリは特に単純ではありませんが、
サービスの手動実験は非常に限られています。CURLを使用してAmazon S3へのリクエストを行うことができます。S3のAMQPバリアントを使用したい場合、マシンに何をインストールする必要がありますか？
RESTとSOAPのデバッグは簡単です。HTTP交換を追跡して分析するだけです。AMQP交換をデバッグするためにどのツールを使用すべきかわからない。
AMQPは優れていますが、イベントに基づく交換という非常に特定の目的のために行われています。AMQPでRPCを実行することは技術的には可能ですが、それは主な目的ではありません。
非同期の側面も重要です。サーバーにリクエストを送信している間、アプリのユーザーインターフェイスをブロックしたくない場合があります。場合によっては、必要以上に物事が難しくなることがあります。ローカルのものが破損しているためにAmazon S3からファイルバックアップを復元し、バックアップを復元する必要がある場合、続行する前にバッチファイルのジョブを完了するには必然的にCURLが必要です、同期操作（特定のタイムアウトを使用）は完全に理にかなっています。
主要な操作のためにRESTを保持します。
製品の入手、
請求書の保存、
そして、メッセージングが実際に意味をなすタスクにAMQPを使用します。
9月からのすべての請求書を処理し、レポートを表示する準備ができたらアプリに通知します（操作に通常2〜10分かかることを前提としています）。
ここでのAMQPの利点は、非同期の側面です。10分間保留されているHTTP要求は、タイムアウトやその他の問題を引き起こす可能性が高くなります。
サポート担当者、データベース管理者、監視チーム、このデータベースを使用するアプリケーションの開発者など、関心のあるすべての人にバックアップが破損したという情報を送信します。
ここでのAMQPの利点は、とりわけ、アプリケーションを変更せずにサブスクライバーを追加できることです。これにより、バックアップを追跡し、破損したものを検出するとアラートをトリガーします。
¹パブリックWebサービスは、必ずしも社外のユーザーが使用するわけではありません。大規模または中規模の企業では、サービスは同じ会社の他の部門で使用されることが多く、サードパーティが使用するものと同じ要件があります。同じ会社であなたのサービスを呼び出す人のことを聞いたからといって、セキュリティの問題を悪用しないという意味ではありません）、適切に文書化する必要があります英語を知っている）など
RESTは、コンポーネント間の相互運用性に特に適した標準テクノロジーです。これは重要な部分であり、他の誰かが利用できるWebサービスを作成するのに最適です。ただし、カスタムプロトコルよりも効率が低いという点で、このような相互運用性の通常の問題があります。
サービスが自分でしか消費されないバックエンドアーキテクチャを作成している場合は、好きなプロトコルを使用できます。相互運用性の高いプロトコルを使用することで制約がなくなります。MQまたはより緊密に結合されたパフォーマンスの高いものを使用できます。どちらを使用するかは、ユースケースによって異なります。メッセージバスは、クライアントが送信するメッセージの受信者を気にしないデータを処理する分散サービスセットに非常に適しています。
202は非同期を決定しますが、なぜRESTを使用したのでしょうか？
AMQPは、ポイントツーポイント通信もサポートしています（たとえば、python-qpid-protonチュートリアルを参照）。REST !=HTTP なので、それを使用してRESTfulインターフェースを実装できます。
AMQPはHTTPよりもはるかに優れたパフォーマンスを発揮します。