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
<--------------------
然后，客户端可以重复地将消息发布到 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 的情况下，我们使用每个消费者的预取值来定义每个消费者在缓冲区中获得多少条消息，在必须确认消息才能获得更多消息之前。
因此，想法是，我们有一个每消费者提要，它被创建；然后可以浏览它（任何拥有足够权限的人都可以浏览它）。
