是否使用HTML5服务器发送事件（SSE）ReSTful？
我无法理解HTML5s服务器发送的事件是否真的适合ReST体系结构。我知道并非HTML5/HTTP的所有方面都需要适合ReST架构。但我想从专家那里知道HTTP的哪一半是SSE（ReSTful的一半还是另一半！）。
一种观点是它是ReSTful的，因为客户端向服务器发出了一个“初始”HTTP GET请求，其余的只能看作是不同内容类型的部分内容响应（“文本/事件流”）
发送的请求不知道有多少响应将作为响应（事件）出现？那是安静的吗？
提出这个问题的动机：我们正在开发应用程序的服务器端，我们希望同时支持ReST客户端（一般）和浏览器（特别是）。虽然SSE适用于大多数HTML5浏览器客户端，但我们不确定SSE是否适合纯ReST客户端的支持。这就是问题所在。
编辑1：正在阅读Roy Fielding的旧文章，他说：“换句话说，单个用户请求会导致潜在的大量服务器义务。因此，善意的用户可能会对分发通知的发布者或代理产生不成比例的负载。在Internet上，我们没有只为善意的用户设计的奢侈，因此在HTTP系统中，我们将此类请求称为拒绝服务漏洞......这就是为什么HTTP中没有标准的通知机制”
这是否意味着SSE不是RESTful？
Edit2：正在查看Twitter的RESTAPI。虽然REST清教徒可能会争论他们的REST API是否真的是/完全是REST，但流式处理和REST之间的区别这一节的标题似乎表明流式处理（甚至SSE）不能被视为ReSTful！？有人反对吗？
共有2个答案
我认为SSE可以被REST API使用。根据Fielding论文，如果我们想将其称为REST，我们必须满足应用程序必须满足的一些架构约束。
- 客户机-服务器体系结构：正常-服务器进行处理时，客户机触发
- 无状态：ok-我们仍然在客户端上存储客户端状态，HTTP仍然是无状态协议
- 缓存：确定-我们必须使用无缓存标头
- 统一界面
- 资源标识：确定-我们使用URI
- 通过表示操作资源：好的-我们可以使用具有相同URI的HTTP方法
- 自描述性消息：好的，部分-我们使用内容类型标题，如果需要，我们可以向数据添加RDF，但没有描述数据是RDF编码的标准。如果支持，我们应该定义文本/事件流rdf MIME类型或类似的类型。）
- 作为应用程序状态引擎的超媒体：ok-我们可以在html" target="_blank">数据中发送链接
顺便说一句，没有这样的规则，你不能同时使用不同的技术。因此，如果需要，可以将REST API和websockets结合使用，但如果websockets部分至少不满足自描述性消息和HATEOAS约束，那么客户端将很难维护。可伸缩性可能是另一个问题，因为其他限制也与此相关。
我认为这取决于：
您的服务器端事件是否使用超媒体和超链接来描述可能的状态更改？
这个问题的答案是它们是否满足应用程序架构中的REST。
现在，这些事件的发送/接收方式可能符合也可能不符合REST——我所读到的关于上交所的一切都表明它们不符合REST。我怀疑这将影响几个原则，尤其是分层——尽管如果中介机构了解上交所的语义学，你可能会否定这一点。
我认为这是正交的，因为它只是浏览器（通过运行的JavaScript）理解的HTML和JavaScript处理指令的一部分。您应该仍然能够将客户端应用程序状态与服务器端资源状态解耦。
我看到的一些关于如何使用SSE处理缩放的建议不适合REST，即引入自定义头（修改协议）。
使用SSE时，您如何尊重REST？
我想看看某种
<代码>
然后，您使用的任何内容类型/资源的处理指令（包括JavaScript之类的按需代码）都会告诉客户机如何订阅和利用此类超链接提供的事件。显然，这些事件的数据本身应该是包含更多控制程序流的超链接的超媒体。（我相信这就是你区分Rest和不Rest的地方）。
在某个时候，浏览器可能会意识到这种链接关系，就像样式表一样，并为您进行一些花哨的连接，所以您所做的只是监听JavaScript中的事件。
虽然我确实认为您的应用程序仍然可以适应SSE周围的REST风格，但它们本身并不是REST（因为您的问题特别是关于它们的使用，而不是它们的实现，我试图弄清楚我在说什么）。
我不喜欢该规范使用HTTP，因为它去掉了很多语义，并有效地通过一个相对丰富的协议来传输一个贫血的协议。这应该是一种好处，但我觉得这就像是卖晚餐来支付午餐一样。
<代码>ReST客户端（一般）和浏览器（特别）
您的浏览器为什么不是REST客户端？浏览器可以说是所有REST客户端中最强大的。我们通过JavaScript坚持使用它们，这让我们不再坚持REST。我怀疑/担心，只要我们继续认为我们的REST-API“客户端”和我们的浏览器客户端根本不同，我们仍将陷于当前的状态——可能是因为所有其他人都在寻找RPC人员不知道需要存在的超链接；）
-
我想知道是否可以为服务器发送的事件（SSE；内容类型：文本/事件流）启用gzip压缩。 根据这本书，似乎有可能：http://chimera.labs.oreilly.com/books/1230000000545/ch16.html 但是我找不到任何带有gzip压缩的SSE示例。我尝试发送带有响应标头字段Content-Encode设置为“gzip”的gzip消息，但没有成功。 为了在SSE周围
-
Server-Send事件 Server-Send事件指的是网页 自动获取来自服务器端的更新。以前也能做到这点，前提是网页必须询问是否有可用的更新。通过服务器发送事件，更新能够自动送达。 支持情况：除了IE浏览器外，其它主流浏览器匀支持服务器发送事件。 检测Server-Send的支持情况 在书写代码时，首先是 检测浏览器是否支持Server-Send，代码如下： if (typeof(Event
-
您好，我正在React中开发一个web应用程序，它使用Nginx从Express服务器接收SSE数据。 JS服务器 索引：JS const events=新事件源（'https://api.myDomain.com/events', ); axios。post（<代码>https://api.myDomain.com/addCart，{客户端：this.state.clientId，购物车：car
-
我正在尝试使用泽西岛的JavaScript SSE。我的资源中有以下代码。我在Java7和Tomcat 7上托管。我没有收到任何错误。但我也没有在页面上看到数据。 我调用发布数据。它确实显示信息。但客户什么都没有。在Firefox中，我确实看到事件多次触发。 这是我使用的参考。https://jersey.java.net/documentation/latest/sse.html 我的Index
-
HTML5 服务器发送事件（server-sent event）允许网页获得来自服务器的更新。 Server-Sent 事件 - 单向消息传递 Server-Sent 事件指的是网页自动获取来自服务器的更新。 以前也可能做到这一点，前提是网页不得不询问是否有可用的更新。通过服务器发送事件，更新能够自动到达。 例子：Facebook/Twitter 更新、估价更新、新的博文、赛事结果等。 浏览器支持
-
我有一个ASP。net core 3.1服务器项目，它有一个非常简单的API发送单向服务器发送事件（SSE），如下所示： 现在，我想通过C#UWP客户端接收这些事件。很遗憾，我只收到第一个事件： 如何在UWP中创建行为以始终监听该连接并接收我可以进一步处理的事件？