19

我无法理解 HTML5s Server-sent-events 是否真的适合 ReST 架构。我了解并非 HTML5/HTTP 的所有方面都需要适应 ReST 架构。但我想从专家那里知道，HTTP 的哪一半是 SSE（ReSTful 的一半或另一半！）。

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

发送的请求不知道会有多少响应作为 response(events) 来？那是休息吗？

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

编辑 1：正在阅读 Roy Fielding 的旧文章，他在其中说：“换句话说，单个用户请求会导致潜在的大量服务器义务。因此，善意的用户可能会对发布者或经纪人产生不成比例的负载，即分发通知。在 Internet 上，我们没有为仁慈的用户设计的奢侈，因此在 HTTP 系统中，我们将此类请求称为拒绝服务攻击......这正是没有标准机制的原因对于 HTTP 中的通知“

这是否意味着 SSE 不是 ReSTful ？

Edit2：正在通过 Twitter 的 REST API。虽然 REST 清教徒可能会争论他们的 REST API 是否真的/完全是 REST，但Streaming 和 REST 之间的差异部分的标题似乎表明 Streaming（甚至 SSE）不能被视为 ReSTful ！？有人反对吗？

4

2 回答 2

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 人不知道需要存在 ;)

于 2013-06-05T18:52:00.093 回答
3

我认为 SSE 可以被 REST API 使用。根据Fielding 论文，如果我们想将其称为 REST，我们有一些应用程序必须满足的架构约束。

  • 客户端-服务器架构：好的- 客户端在服务器进行处理时触发
  • 无状态：好的- 我们仍然在客户端上存储客户端状态，HTTP 仍然是无状态协议
  • 缓存：好的- 我们必须不使用缓存头
  • 统一界面
    • 资源识别：好的- 我们使用 URI
    • 通过表示操作资源：好的- 我们可以使用具有相同 URI 的 HTTP 方法
    • 自描述消息：好的，部分- 我们使用内容类型标头，如果需要，我们可以将 RDF 添加到数据中，但是没有描述数据是 RDF 编码的标准。如果支持，我们应该定义一个 text/event-stream+rdf MIME 类型或类似的东西。）
    • 超媒体作为应用程序状态的引擎：好的- 我们可以在数据中发送链接
  • 分层系统：好的- 我们可以添加其他层，也可以转换数据流。管道和过滤器，其中泵是服务器，过滤器是这些层，水槽是客户端
  • 按需代码：好的- 可选，没关系

顺便提一句。没有这样的规则，你不能一起使用不同的技术。因此，您可以根据需要一起使用例如 REST API 和 websockets，但如果 websockets 部分至少不符合自描述消息和 HATEOAS 约束，则客户端将难以维护。可扩展性可能是另一个问题，因为其他约束与此有关。

于 2015-10-06T12:19:40.523 回答