REST中基于事件的交互样式

Question

目前，我正在努力解决一个涉及REST的设计问题。我正在设计的应用程序需要发送事件并支持发布/订阅风格的交互。我无法提出一个设计来提供这些交互风格，而不打破其余的“无状态交互”约束。我并不像某些人看起来那样反对轮询(轮询太糟糕了)，但是我的应用程序需要基于事件的和pub/sub风格的交互(轮询对我来说不是一种选择)。所以，我的问题是：

1. 我是否可以设计一个支持基于事件和发布/子交互的RESTful应用程序，而不打破其余的禁忌呢？
2. REST风格是否适合这种交互风格？

Answer 1

我推荐邓肯·克拉格( Duncan )的分布式观测器模式是个不错的读物(有点难懂，但值得一试)。

正如其他人所指出的，您可能需要使用轮询，但是正如您正确地说的那样，订阅者可以注册他们自己的兴趣(POST创建订阅)。如果您将订阅视为自己的资源，即发行者和订阅者之间的契约，那么我不会将其视为一个中断REST约束(关于应用程序状态和资源状态之间的区别，请参见状态和RESTful网络服务第217页的无状态状态)

Answer 2

我想您的意思是服务器应该将事件通知客户端。我看不出具体的技术有什么意义:您将面临同样的问题，必须从同一个池中选择解决方案，而不管是使用REST、基于SOAP的web服务还是任何其他选择。

基本问题是，您的服务器能启动连接吗？作为补充，客户可以监听端口吗？如果是这样，则客户端注册(sub)，服务器通知事件(pub)。注册操作和通知事件都可以是RESTful。

您需要服务器启动的连接和侦听客户端。如果两者都不是一个选项(例如，因为客户端是一个web浏览器)，那么您将不得不进行轮询(如果您正在处理一个浏览器，也可以查看类似websockets的内容)。仔细设计您的轮询:服务器对轮询事件的响应应该在客户机再次轮询之前指示最小延迟。服务器的初始实现可以返回此延迟值的常量，但稍后(假设客户机行为良好)，这将允许您控制服务器上的负载，区分关键客户端和不太关键的客户端，等等。

当然，投票可以是RESTful。

Answer 3

我看不出为什么RESTful接口不应该支持事件。

请注意，这必须通过轮询来完成；即使使用SOAP也是如此。

虽然您的web服务器绝对应该保持无状态，但是您可能在后端的某个地方有一个DB。可以通过添加订阅表来使用此DB处理对事件的订阅。