使用HTML5 Server-sent-events(SSE)ReSTful？

Question

我无法理解HTML5s Server-sent-events是否真的适合ReST架构.我知道并非HTML5/HTTP的所有方面都需要适合ReST架构.但我想知道专家,其中一半的HTTP是SSE(ReSTful一半或另一半!).

一种观点可能是它是ReSTful,因为从客户端到服务器有一个"初始"HTTP GET请求,剩下的只能被看作只是不同内容类型的部分内容响应("text/event-流")

发送的请求不知道响应(事件)会有多少响应？这是Restful吗？

问题的动机:我们正在开发应用程序的服务器端,我们希望同时支持ReST客户端(通常)和浏览器(特别是).虽然SSE适用于大多数HTML5浏览器客户端,但我们不确定SSE是否适合纯ReST客户端的支持.因此问题.

Edit1:正在阅读Roy Fielding的旧文章,他说:"换句话说,单个用户请求会导致潜在的大量服务器义务.因此,一个仁慈的用户可能会对发布者或代理产生不成比例的负载.在互联网上,我们没有为善意用户设计的奢侈品,因此在HTTP系统中我们称这种请求为拒绝服务攻击.... 这正是为什么没有标准机制用于HTTP中的通知 "

这是否意味着SSE不是Restful？

Edit2:正在浏览Twitter的REST API.虽然REST puritans可能会争论他们的REST API是否真的/完全REST,但Streaming和REST之间的差异部分的标题似乎表明Streaming(甚至SSE)不能被认为是ReSTful!有人认为吗？

Answer 1

我认为这取决于：

您的服务器端事件是否使用超媒体和超链接来描述可能的状态变化？

这个问题的答案就是它们是否满足您的应用程序架构中的 REST。

现在，发送/接收这些事件的方式可能遵循 REST，也可能不遵循 REST——我读到的有关 SSE 的所有内容都表明它们不遵循 REST。我怀疑这会影响几个原则，尤其是分层——尽管如果中介机构了解 SSE 的语义，你可能会否定这一点。

我认为这是正交的，因为它只是浏览器（通过它运行的 JavaScript）理解的 HTML 和 JavaScript 处理指令的一部分。您仍然应该能够将客户端应用程序状态与服务器端资源状态分离。

我看到的一些关于如何使用 SSE 处理扩展的建议不适合 REST - 即引入自定义标头（修改协议）。

使用 SSE 时如何尊重 REST？

我想看看某种

<link rel="event" href="http://example.com/user/1" />

然后，您正在使用的任何内容类型/资源的处理指令（包括按需代码，例如 JavaScript）都会告诉客户端如何订阅和利用从此类超链接提供的事件。显然，这些事件的数据本身应该是包含更多控制程序流的超链接的超媒体。（我相信这就是您区分 REST 和非 REST 的地方）。

在某些时候，浏览器可能会意识到这种链接关系 - 就像 astylesheet和 为您做一些奇特的连接一样，因此您所做的只是侦听 JavaScript 中的事件。

虽然我确实认为您的应用程序仍然可以适应 SSE 周围的 REST 风格，但它们本身并不是 REST （因为您的问题具体是关于它们的使用，而不是它们的实现，所以我试图弄清楚我所说的内容）。

我不喜欢该规范使用 HTTP，因为它消除了很多语义，并通过其他相对丰富的协议有效地传输了贫乏的协议。这应该是一种好处，但在我看来，这是卖晚餐来支付午餐的费用。

ReST clients (in general) and Browsers (in particular).

为什么你的浏览器不是 REST 客户端？浏览器可以说是最 REST 的客户端。正是我们通过 JavaScript 给它们添加了这些废话，才导致我们不再遵守 REST。我怀疑/担心，只要我们继续认为我们的 REST-API“客户端”和我们的浏览器客户端有本质上的不同，我们仍然会陷入当前的状态 - 大概是因为所有 REST 人员都在寻找一个超链接，人们不知道 RPC 的存在必要性；）