REST中基于事件的交互风格

我目前正在努力解决一个涉及REST的设计问题。我正在设计的应用程序需要发送事件并支持发布/订阅式的交互。我无法想出一个设计来提供这些交互样式，而不打破其余的“无状态交互”约束。我并不像有些人那样反对轮询（轮询很糟糕），但我的应用程序要求基于事件和发布/订阅方式的交互（轮询不是我的选项）。所以，我的问题是：

我是否可以设计一个RESTful应用程序，在不破坏REST约束的情况下支持基于事件和发布/订阅的交互

休息方式适合这种互动方式吗

---

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

请注意，这必须通过投票来完成；即使你用肥皂来代替，这也是事实

---

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

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

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

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

当然，投票可以是安静的。

我推荐邓肯·克拉格（Duncan Cragg）的这本书作为一本好书（虽然有点难懂，但值得一读）

---

正如其他人所指出的，您可能需要使用轮询，但正如您正确地说，订阅者可以注册他们自己的兴趣（发布以创建订阅）。如果您将订阅视为自己的资源，即发布者和订阅者之间的契约，那么我不会将其视为破坏REST约束（请参阅第217页的状态和无状态，了解应用程序和资源状态之间的差异）

快速检查REST约束：

• 客户端-服务器体系结构
• 无国籍
• 缓存
• 均匀界面
  • 资源的识别
  • 通过表示操纵资源
  • 自我描述信息
  • 应用状态引擎的超媒体
• 分层系统
• 按需编码（可选）

菲尔丁博士论文：

客户机-服务器样式是最常见的样式 基于网络的应用程序的体系结构样式。服务器 组件提供一组服务，侦听这些服务上的请求 服务。希望执行服务的客户端组件， 通过连接器向服务器发送请求。服务器 拒绝或执行请求，并将响应发送回 客户

顺便说一句，基于事件的系统可能会违反大多数约束。很难在没有客户端的情况下定义

超媒体应用程序状态的引擎

（因为

应用程序状态

的另一个名称是

客户端状态

）和超链接（因为它们在发布/订阅中毫无意义），等等

无论如何，如何设计一个类似于REST的基于事件的系统是一个有趣的问题。我认为您应该发布包含RDF的自描述性消息，但这只是一个提示。轮询可以是一个简单的过程，但如果我是你，我不会试图在基于事件的系统上强制REST

2016.05.15更新。

---

据我所知，客户机-服务器体系结构——Fielding在他的论文中描述并使用always REQ/REP通信。客户端发送请求，REST服务响应。如果您想在不违反客户机-服务器约束的情况下实现PUB/SUB之类的功能，唯一的方法就是使用轮询。如果您不想使用轮询，则使用ofc。您可以同时使用REST服务和websocket服务，这是不被禁止的…

WebHook就是这个问题的答案。它们允许在不违反REST原则的情况下进行活动。

嗨，科林，谢谢链接。这很有帮助。您是对的，将子描述作为资源不会打破REST约束。再次感谢，这真的违反了客户机-服务器体系结构吗？如果客户端A向服务器B提供回调以通知更改，则B将成为A的客户端，而A将成为B的服务器。是否要求组件不能同时是客户端和服务器？@user3285954这对我来说没有意义，但我不确定。：-）@user3285954让我们从另一个方面来检查这一点。理论上，可以使用循环依赖。因此，您有两个相互依赖的REST服务。这显然违反了分层系统约束：“分层系统是分层组织的，每一层都向其上一层提供服务，并使用la的服务