我无法理解HTML5s Server-sent-events是否真的适合ReST架构。我知道并非HTML5 / HTTP的所有方面都需要适合ReST架构。但我想知道专家，其中一半的HTTP是SSE（ReSTful一半或另一半！）。
一个视图可能是ReSTful，因为从客户端到服务器有一个“初始”HTTP GET请求，剩下的只能看作是不同内容类型的部分内容响应（“text” /事件流“）
发送的请求不知道响应（事件）会有多少响应？这是Restful吗？
问题的动机：我们正在开发应用程序的服务器端，我们希望同时支持ReST客户端（通常）和浏览器（特别是）。虽然SSE适用于大多数HTML5浏览器客户端，但我们不确定SSE是否适合纯ReST客户端的支持。因此问题。
EDIT1 ： 正在读罗伊菲尔丁的旧article，他在那里说： “换句话说，单个用户请求会导致潜在的大量服务器义务。因此，一个仁慈的用户可能会对发布通知的发布者或代理产生不成比例的负载。 ，我们没有为善意用户设计的奢侈品，因此在HTTP系统中我们称这种请求为拒绝服务攻击.... 这就是为什么没有标准的通知机制HTTP “
这是否意味着SSE不是Restful？
EDIT2 ： 正在浏览Twitter的REST API。 虽然REST puritans可能会争论他们的REST API是否真的/完全REST，但只有Differences between Streaming and REST部分的标题似乎表明Streaming（甚至SSE）不能被认为是ReSTful！有人争辩说吗？
答案 0 :(得分：4)
我认为这取决于：
您的服务器端事件是否使用超媒体和超链接来描述可能的状态更改？
该问题的答案是他们是否在您的应用程序架构中满足REST的答案。
现在，发送/接收这些事件的方式可能会也可能不会遵循REST - 我所读到的关于SSE的所有内容都表明它们没有。我怀疑它会影响几个原则，特别是分层 - 尽管如果中间人知道SSE的语义，你可能会否定这一点。
我认为这是正交的，因为它只是浏览器（通过运行的JavaScript）理解的HTML和JavaScript处理指令的一部分。您仍然可以将客户端应用程序状态与服务器端资源状态分离。
我在如何使用SSE处理扩展方面看到的一些建议不适合REST - 即引入自定义标头（修改协议）。
在使用SSE时如何尊重REST？
我想看一些
<link rel="event" href="http://example.com/user/1" />
然后，您正在使用的任何内容类型/资源的处理指令（包括JavaScript的按需代码）告诉客户端如何订阅和利用从这样的超链接提供的事件。显然，这些事件的数据本身应该是超媒体，包含更多控制程序流的超链接。 （这是我相信你在REST和非REST之间做出区分的地方。）
在某些时候，浏览器可能会意识到这种链接关系 - 就像stylesheet一样，为你做一些花哨的连线，所以你只需要用JavaScript来监听事件。
虽然我确实认为你的应用程序仍然可以适应SSE的REST风格，但它们本身并不是REST（因为你的问题是关于它们的使用，而不是它们的实现，我试图清楚我要说的是什么）
我不喜欢规范使用HTTP，因为它消除了许多语义，并通过相对较富的协议有效地隧道化贫血协议。这可能是一种好处，但是因为卖晚餐来支付午餐而感到震惊。
ReST clients (in general) and Browsers (in particular).
您的浏览器如何不是REST客户端？浏览器可以说是所有REST客户端中最多的。这是我们通过JavaScript坚持到底的所有废话，然后停止遵守REST。我怀疑/担心只要我们继续考虑我们的REST-API'客户'和我们的浏览器客户端根本不同，我们仍然会陷入当前状态 - 可能是因为所有REST人都在寻找一个超链接RPC人员不知道需要存在;）
答案 1 :(得分：1)
我认为SSE可以被REST API使用。根据{{3}}，我们有一些架构限制，应用程序必须满足，如果我们想将其称为REST。
顺便说一下。没有这样的规则，你不能一起使用不同的技术。因此，如果需要，您可以将REST API和websockets一起使用，但如果websockets部分至少不符合自描述性消息和HATEOAS约束，那么客户端将难以维护。可伸缩性可能是另一个问题，因为其他约束与此有关。