使用Websockets代替RESTful HTTP的缺陷是什么？

Question

我目前正在开发一个项目，该项目要求客户端请求大量工作并将其发送到服务器。然后，服务器将作业分开，并响应一组URL，以便客户端进行GET调用并回送数据。我是该项目的新手，我目前正在使用Spring websockets来提高效率。而不是客户端不断ping服务器以查看它是否已准备好返回结果，websocket现在只是直接联系客户端万岁！

让websockets从头到尾管理整个过程是不是一个坏主意？我正在使用带有Spring websockets的STOMP，是否仍然存在抛弃REST的主要问题？

Answer 1

使用RESTful HTTP，您有一个无状态请求/响应系统，客户端发送请求，服务器返回响应。

对于webSockets，您有一个有状态（或可能有状态）的消息传递系统，其中消息可以以任何方式发送，并且发送任何给定消息的开销低于RESTful HTTP请求/响应。

两者结构完全不同，具有不同的优势。

连接的webSocket的主要优点是：

1. 双向沟通。因此，服务器可以随时通知客户端任何内容。因此，不是在某个定期间隔内轮询服务器以查看是否有新内容，客户端可以建立webSocket并只监听来自服务器的任何消息。从服务器的角度来看，当客户端感兴趣的事件发生时，服务器只是向客户端发送消息。服务器无法使用普通HTTP执行此操作。

2. 每条消息的开销更低。如果您预计客户端和服务器之间会有大量流量，那么使用webSocket的每条消息的开销就会降低。这是因为已建立TCP连接，您只需在已打开的套接字上发送消息。使用HTTP REST请求，您必须首先建立TCP连接，这是客户端和服务器之间的几个来回连接。然后，您发送HTTP请求，接收响应并关闭TCP连接。 HTTP请求必然包括一些开销，例如与该服务器对齐的所有cookie，即使这些与特定请求无关。如果客户端和服务器正在使用HTTP / 2（最新的HTTP规范），则在这方面可以提供一些额外的效率，因为单个TCP连接不仅可以用于单个请求/响应。如果您在TCP级别上绘制了所有请求/响应，只是为了发出https REST请求/响应，那么与仅通过已建立的webSocket发送消息相比，您会感到惊讶。 p>

3. 在某些情况下更高规模。每个消息的开销更低，并且没有客户端轮询以确定某些内容是否是新内容，这可以增加可扩展性（给定服务器的客户端数量更多）可以服务）。 webSocket可伸缩性也存在缺点（见下文）。

4. 有状态连接。无需借助Cookie和会话ID，您可以直接在程序中为给定连接存储状态。虽然已经通过无状态连接进行了大量的开发来解决大多数问题，但有时它只是简单的状态连接。

RESTful HTTP请求/响应的主要优点是：

1. 普遍支持。很难获得比HTTP更普遍的支持。虽然webSockets现在享有相对较好的支持，但仍有一些情况下webSocket支持不能定期提供。

2. 与更多服务器环境兼容。有些服务器环境不允许长时间运行的服务器进程（某些共享托管情况）。这些环境可以支持HTTP请求，但不支持长时间运行的webSocket连接。

3. 在某些情况下更高规模。连续连接的TCP套接字的webSocket要求为HTTP请求不要求的服务器基础结构添加了一些新的扩展要求。因此，这最终成为一个权衡空间。如果webSockets的优点并非真正需要或以显着的方式使用，那么HTTP请求实际上可能会更好地扩展。这绝对取决于具体的使用情况。

4. 对于一次性请求/响应，单个HTTP请求比建立webSocket，使用它然后关闭它更有效。这是因为打开webSocket以HTTP请求/响应开始，然后在双方同意升级到webSocket连接之后，可以发送实际的webSocket消息。

5. 无状态。如果通过无状态基础设施使您的工作变得更加复杂，那么无状态世界可以使扩展变得更加容易（只需在负载均衡器后面添加更多服务器进程）。

6. 自动缓存。使用正确的服务器设置，http响应可以由浏览器或代理缓存。对于通过webSockets发送的请求，没有这种内置机制。

所以，要解决你问这个问题的方式：

  

使用websockets代替RESTful HTTP会有什么陷阱？

1. 在大规模（数十万个客户端）中，您可能需要做一些特殊的服务器工作才能支持大量同时连接的WebSocket。

2. 所有可能的客户或工具集都不支持webSockets或通过它们发出的请求到支持HTTP请求的同一级别。

3. 一些较便宜的服务器环境不支持支持webSockets所需的长时间运行的服务器进程。

如果您的应用程序将进度通知重新发送回客户端非常重要，您可以使用长时间运行的http连接，继续向下发送进度，也可以使用webSocket。 webSocket可能更容易。如果您在此特定活动的相对较短的持续时间内确实只需要webSocket，那么您可能会发现只有在您需要能够将数据推送到客户端的时间段内使用webSocket才能获得最佳的权衡集。然后使用http请求进行正常的请求/响应活动。

Answer 2

这实际上取决于您的要求。与Websockets相比，REST服务可以更加透明，更容易被开发人员接收。

使用Websockets，您可以删除RESTful Web服务提供的大多数优势，例如通过URI引用资源的功能。你真正应该做的是弄清楚REST和超媒体的优点是什么，并根据这些优势决定这些优势是否对你很重要。

当然，完全有可能创建一个RESTful Web服务，并使用基于websocket的API来增强它以进行实时响应。

但是，如果您要创建的服务只能在受控环境中使用，唯一的缺点可能是并非每个客户端都支持websockets，而几乎任何类型的环境都可以执行简单的http调用。