RESTful URIとPubSubトピックの関係
私は、RESTfulアーキテクチャに非常によく適合するシステムを設計しています。ユーザーは、ルートノードからリソース階層をナビゲートできます。各リソースは他のリソースにリンクします。リソースにはURIなどがあります。これは、多くの点で、そこにあるCRUD Webアプリケーションの99％とよく似ています。
少し違うところは、Pub/Subモデルをこのアーキテクチャに統合することです。したがって、リソースが変更されたときに、関連するサブスクライバーにプッシュされる更新をサポートするアーキテクチャが必要です。
私の質問の多くは、Pub/Subの「トピック」がRESTfulな「URI」とどのように関連しているかに関連しています。本当に私はトピックとしてURIを使いたいだけです。私は多くのシナリオで完全に理にかなっているように感じます-しかし私はこれについて疑いの余地があり、実際にこれを行っているアーキテクチャを見つけることができません。
奇妙なのは、一部のURIがクエリであり、このモデルに簡単に適合しないことです。 pub/sub動的クエリをサポートするには複雑すぎるため、意図も必要もありませんが、この概念がRESTfulシステムに広く実装されているという事実により、pub/subのトピックとしてのURIの使用に不一致または制限があるように感じますシステム。
現時点での私の解決策は、「正規の」URI（つまり、正規の場所にある単一のリソースを参照するURI）は、トピックとして使用するのに問題がない、または良いことです。しかし、他の人がこれをしているのを見ないので、私の自信は低いです。
どんな考えでも感謝します。
（RESTリソースから）のURIをトピックにマッピングすると、モデリングの内容に応じて、完全なマッピングが得られます。
簡単な例を通して、私はこのマッピングを実行する方法についていくつかのヒントを提供しようとします。例として、2つのAPI、a REST API（リソース）とMQTT API（トピック）を取り上げます。
ちなみに、 [〜＃〜] mqtt [〜＃〜] は、モノのインターネットおよびM2Mのpub/subプロトコルです。MQTTブローカーには、クライアントが公開できるトピックがいくつかあります（ PUB topic1/topic2/...）またはサブスクライブ（SUB topic1/topic2/...）。
ヒント1：リソース表現はメッセージです
アイデアは、対応するトピック名でリソースURIをマップすることです。したがって、リソースURIからのリソース表現は、トピック内のメッセージに対応します。
リソース名/people/:idがあるとします。対応するトピック名は/people/:idになります。
したがって、クライアントがPUT /people/1 { "loveBeer":true }を作成すると、（SUB /people/1を介して）このトピックにサブスクライブしているクライアントは通知を受け取ります。 PATCHも使用できることに注意してください。同じことが逆に当てはまります。クライアントがトピック[PUB /people/1 "loveBeer":true]にメッセージを投稿すると、対応するリソースが更新されます。
あなたはこの種のアーキテクチャで終わるでしょう（写真は this blog から取得されます）： 
ヒント2：リソースの作成もメッセージです
前の例から、あなたは考えることができます...
ねえ、クライアントが
POST /peopleを通じて新しいリソースを作成するのはどうですか？
新しいリソースを作成し、対応するトピック（/people）にメッセージを公開します
たとえば、クライアントがPOST /people { "name":"schneider", loveBeer:true}を実行するとします。 SUB /peopleを実行したクライアントは通知を受け取ります
だからあなたはもう一度考えて言うことができます：
ねえ、クライアントが
PUB /peopleを使用してトピックのメッセージを公開するのはどうですか？逆に、トピック/peopleにメッセージを作成し、新しいサブリソース/people/:newidを作成します
クライアントがPUB /people {"name":"Ailurus", "loveBeer":true}を作成し、メッセージを受信すると、新しいリソース/people/42が作成され、クライアントが/peopleにサブスクライブしていることが通知されると想像してください。
ボーナスヒント：メタデータを検討する
リソースURI /トピック間のマッピングに実際には関連しないので、それは実際にはヒントではありません:)
この blog から、公開されたメッセージのペイロードにメタデータを追加できます（ただし、リソース表現には追加できません）。
トピックにサブスクライブするMQTTクライアントは、リソースが更新または作成されたかどうかを認識しないため、RESTクライアントはこの情報を（リソースが作成されると、ロケーションヘッダーを介して）知っているため） "event": "created"や `" event "などのメタデータを追加することを検討してください：" modified "
{"event": "created"}をペイロードに追加するだけでなく、リソースがいつ作成されるかを考えて、{"event": "created", "location": "people/42"}などのリソースURI /トピック名を指定することもできます。
POSTトピックURIを使用してトピックへのサブスクリプションを作成できます。これにより、個々のサブスクライバーの応答で返されるキューが生成されます。
このキューURIでPOSTを使用すると、ユーザーに配信する必要があるアイテムのフィード（メッセージのURI）を含む新しいURIが作成されます。この現在のフィード状態でGETを実行すると、フィードが参照する選択したアイテムをGETできます。アイテムが共有されている場合（これはおそらくほとんどの人が望んでいることです）、それらを単に削除することはできません。POSTを再度指定して、配信済みとしてマークする必要があります。
キューURIの新しいPOSTは、現在キューに入れられているアイテム（おそらく、配信済みとしてマークされていないもの）を含むフィードを作成します。しかし、これは、メッセージ。
もちろん、サブスクリプションを解除したいときにサブスクリプションを削除することができます。システムをクリーンに保つために、一部のURI（フィードと最終的にはアイテム）に有効期限の制限を設けることをお勧めします。