我目前正在做一个项目，该项目需要客户端请求一项大工作并将其发送到服务器。然后服务器划分作业并以一组 url 响应客户端，以进行 GET 调用并流回数据。我是该项目的新手，我目前正在使用 Spring websockets 来提高效率。与客户端不断 ping 服务器以查看是否有准备好返回的结果不同，websocket 现在将直接联系客户端万岁！
让 websockets 从头到尾管理整个过程是不是一个坏主意？我正在将 STOMP 与 Spring websockets 一起使用，放弃 REST 还会存在重大问题吗？
【问题讨论】：
标签： rest http websocket client-server spring-websocket
这真的取决于您的要求。与 Websockets 相比，REST 服务更透明，更易于开发人员使用。
使用 Websocket，您消除了 RESTful Web 服务提供的大部分优势，例如通过 URI 引用资源的能力。你真正应该做的是弄清楚 REST 和超媒体的优势是什么，并据此决定这些优势对你是否重要。
当然，完全可以创建一个 RESTful web 服务，并使用基于 websocket 的 API 来增强它以实现实时响应。
但是，如果您正在创建一个只有您将在受控环境中使用的服务，唯一的缺点可能是并非每个客户端都支持 websocket，而几乎任何类型的环境都可以进行简单的 http 调用。
【讨论】：
使用 RESTful HTTP，您有一个无状态请求/响应系统，客户端发送请求，服务器返回响应。
使用 webSockets，您有一个有状态（或可能有状态）的消息传递系统，其中消息可以通过任一方式发送，并且发送消息的开销低于使用 RESTful HTTP 请求/响应。 p>
两者是完全不同的结构，具有不同的强度。
连接的 webSocket 的主要优点是：
双向通信。因此，服务器可以随时通知客户端任何事情。因此，客户端可以建立一个 webSocket 并监听来自服务器的任何消息，而不是定期轮询服务器以查看是否有新内容。从服务器的角度来看，当客户端感兴趣的事件发生时，服务器只是向客户端发送一条消息。服务器无法使用纯 HTTP 执行此操作。
每条消息的开销更低。如果您预计客户端和服务器之间会出现大量流量，那么使用 webSocket 时每条消息的开销会更低。这是因为 TCP 连接已经建立，您只需在已经打开的套接字上发送消息。对于 HTTP REST 请求，您必须首先建立一个 TCP 连接，该连接在客户端和服务器之间来回多次。然后，您发送 HTTP 请求，接收响应并关闭 TCP 连接。 HTTP 请求必然会包含一些开销，例如与该服务器对齐的所有 cookie，即使它们与特定请求无关。如果客户端和服务器都在使用 HTTP/2（最新的 HTTP 规范），那么它在这方面允许一些额外的效率，因为单个 TCP 连接可以用于多个请求/响应。如果您将 TCP 级别的所有请求/响应绘制成图表，只是为了发出 https REST 请求/响应，那么与仅通过已建立的 webSocket 发送消息相比，您会感到惊讶。
在某些情况下可扩展性更高。每条消息的开销较低，并且无需客户端轮询来确定是否有新内容，这可以提高可扩展性（给定服务器可以服务的客户端数量更多） . webSocket 的可扩展性也有缺点（见下文）。
有状态连接。无需借助 cookie 和会话 ID，您可以直接在程序中为给定连接存储状态。虽然已经对无状态连接进行了大量开发来解决大多数问题，但有时使用有状态连接会更简单。
RESTful HTTP 请求/响应的主要优点是：
普遍支持。很难获得比 HTTP 更普遍的支持。虽然 webSockets 现在享有相对较好的支持，但仍有一些情况下 webSocket 支持不定期可用。
兼容更多服务器环境。有些服务器环境不允许长时间运行服务器进程（某些共享托管情况）。这些环境可以支持 HTTP 请求，但不支持长时间运行的 webSocket 连接。
在某些情况下更高的规模。持续连接的 TCP 套接字的 webSocket 要求为服务器基础结构增加了一些 HTTP 请求不需要的新规模要求。因此，这最终成为一个权衡空间。如果 webSockets 的优势不是真正需要或被大量使用，那么 HTTP 请求实际上可能会更好地扩展。这绝对取决于具体的使用情况。
对于一次性请求/响应，单个 HTTP 请求比建立 webSocket、使用它然后关闭它更有效。这是因为打开一个 webSocket 是从一个 HTTP 请求/响应开始，然后双方同意升级到一个 webSocket 连接后，才能发送真正的 webSocket 消息。
无状态。如果您的工作没有因拥有无状态基础设施而变得更加复杂，那么无状态世界可以使扩展或故障转移变得更加容易（只需在负载均衡器后面添加或删除服务器进程)。
可自动缓存。通过正确的服务器设置，浏览器或代理可以缓存 http 响应。对于通过 webSockets 发送的请求，没有这样的内置机制。
所以，为了解决您提出问题的方式：
使用 websocket 代替 RESTful HTTP 有哪些陷阱？
在大规模（数十万客户端）中，您可能需要做一些特殊的服务器工作才能支持大量同时连接的 webSocket。
所有可能的客户端或工具集都不支持 webSocket 或通过它们发出的请求与支持 HTTP 请求的级别相同。
一些较便宜的服务器环境不支持支持 webSockets 所需的长时间运行的服务器进程。
如果将进度通知返回给客户端对您的应用程序很重要，您可以使用长时间运行的 http 连接并发送持续的进度，或者您可以使用 webSocket。 webSocket 可能更容易。如果您真的只在此特定活动的相对较短的持续时间内需要 webSocket，那么您可能会发现最好的整体权衡是仅在您需要能够将数据推送到客户端的持续时间内使用 webSocket，并且然后使用 http 请求进行正常的请求/响应活动。
【讨论】：