RESTful 佇列
開發人員 > 想法 > RESTful 佇列
RESTful 佇列
本文旨在闡述理想的 RESTful 介面，以因應訊息佇列的議題
佇列與 REST 的問題
將訊息佇列建構為真正的 RESTful API 的主要問題之一是，訊息佇列本質上是一個負載平衡器，因此每個佇列的消費者看到的基本上是不同的佇列；因為每個訊息只有一個消費者會收到副本。
此外，如果消費者消失，則與該消費者相關的訊息需要重新分配給另一個消費者。因此，主要棘手的部分實際上是消費者找出它可以消費哪些訊息的操作。
佇列管理
本節處理佇列的一般瀏覽和建立/刪除。
瀏覽可用的佇列
要瀏覽佇列，它們通常是一個層次結構，因此讓我們像任何 APP 集合一樣瀏覽它們
GET /queues
-------------------->
200 OK
Atom Feed with one entry per directory/category/queue
<--------------------
瀏覽佇列的訊息
GET /queues/uk/products/books/computers
-------------------->
200 OK
Atom Feed with one entry per pending message
<--------------------
請注意，我們可以將佇列顯示為樹狀結構，例如
GET /queues/uk/products
-------------------->
200 OK
Atom Feed with one entry per queue in uk.products.* together with any child catgory/directory
<--------------------
建立佇列
建立佇列通常是等冪的；因為您實際上只是建立一個可以發布的名稱。
POST /queues
-------------------->
201 OK
Location: someUniqueUrlForTheNewQueueToBePostedTo
<--------------------
刪除佇列
DELETE /queues/foo.bar
-------------------->
200 OK
<--------------------
傳送到佇列
傳送到佇列是常見的 APP 風格的雙重請求；一個用於獲取要發布的唯一 URI，第二個用於執行實際的發布...
POST /queues/foo.bar
-------------------->
201 OK
Location: someUniqueUrlForTheNewMessageToBePostedTo
<--------------------
然後，客戶端可以重複地將訊息 POST 到 someUniqueUrlForTheNewMessageToBePostedTo，直到它收到 200 OK，這可以避免重複。
單一請求的可選替代方案
如果智慧型客戶端能夠為訊息產生一個系統範圍唯一的 GUID (id)，則伺服器端可以忽略重複項。 因此，可以無需採用上述雙重請求的方法來發布到佇列
POST /queues/foo.bar?guid=clientGeneratedUniqueId
-------------------->
200 OK
<--------------------
從佇列消費
如上所述，這是將訊息佇列對應到 REST 的棘手部分。
因此，我們為佇列的訂閱引入一個資源。 訂閱會保持活動狀態直到達到某個逾時值 - 因此訂閱是一種租約。
建立訂閱時，可以提供各種不同的資料，例如
- 預取緩衝區
- 它適用於哪些目的地（例如，我們可以使用萬用字元）
- 是否應用選擇器/篩選器
建立訂閱
POST /subscriptions
-------------------->
201 OK
Location: subscriptionUri
<--------------------
實際的訂閱資料可以是表單編碼的鍵/值對。
刪除訂閱
良好的客戶端會在不再需要訂閱時刪除它們；儘管它們最終會逾時。
DELETE subscriptionUri
-------------------->
200 OK
<--------------------
消費訊息
您可以透過瀏覽訂閱（如任何 APP 資源）來消費訊息，然後在您完成處理後 DELETE 該訊息。
GET subscriptionUri
-------------------->
200 OK
Atom Feed with one entry per message associated to this subscription
<--------------------
然後確認已處理特定的訊息
DELETE messageUri
-------------------->
200 OK
<--------------------
與 APP 的差異
以上幾乎所有內容都可以是純粹的 APP。 唯一的真正區別在於，每個消費者都有自己要消費的訊息串流。
在 ActiveMQ Classic 的情況下，我們使用每個消費者的預取值來定義每個消費者在其緩衝區中獲得多少訊息，然後必須確認訊息才能獲得更多訊息。
因此，我們的想法是我們有一個建立的每個消費者串流；然後可以瀏覽它（任何有足夠業力的人）。
