Websocket API 取代 REST API？ [关闭]

Posted 2023-03-08

【中文标题】Websocket API 取代 REST API？ [关闭]

【英文标题】：Websocket API to replace REST API? [closed]

【发布时间】：2011-10-11 23:39:09

【问题描述】：

我有一个应用程序，其主要功能通过 websockets 或长轮询实时工作。

然而，大部分网站都是以 RESTful 方式编写的，这对未来的应用程序和其他客户端来说非常有用。但是，我正在考虑为所有站点功能转换到 websocket API，而不是 REST。这将使我更容易将实时功能集成到网站的所有部分。这会使构建应用程序或移动客户端变得更加困难吗？

我发现有些人已经在做这样的事情了：SocketStream

【问题讨论】：

@Stegi 长轮询作为后备工作足够好，而不是超级担心。

Harry 7 年后的今天，它对你有什么影响？想知道，因为我也想朝那个方向前进。 @哈利

@DmitryKudryavtsev 我最终没有这样做。传统方法对我来说效果很好，而且难度也不大。

【参考方案1】：

我想指出 this blog post 这取决于我，这个问题的最佳答案。

简而言之，是的

这篇文章包含此类 API 的所有最佳实践。

【参考方案2】：

我学到了一点教训（艰难的方式）。我制作了一个在 Ubuntu AWS EC2 云服务（使用强大的 GPU）上运行的数字处理应用程序，我想为它制作一个前端，以便实时观察它的进度。 由于它需要实时数据，很明显我需要 websockets 来推送更新。

它从概念验证开始，效果很好。但是当我们想让它对公众可用时，我们必须添加用户会话，所以我们需要登录功能。而且无论你怎么看，websocket 都必须知道它与哪个用户打交道，所以我们采取了使用 websocket 对用户进行身份验证的捷径。看起来很明显，也很方便。

我们实际上不得不花一些时间来确保连接可靠。我们从一些便宜的 websocket 教程开始，但发现我们的实现在连接断开时无法自动重新连接。当我们切换到 socket-io 时，这一切都得到了改善。 Socket-io 是必须的！

说了这么多，老实说，我认为 我们错过了一些很棒的 socket-io 功能。 Socket-io 可以提供更多，我敢肯定，如果你接受在您的初始设计中考虑到它，您可以从中获得更多收益。相比之下，我们只是用 socket-io 的 websocket 功能替换了旧的 websocket，仅此而已。 （没有房间，没有频道，......）重新设计本可以让一切变得更强大。但我们没有时间。这是我们下一个项目要记住的事情。

接下来我们开始存储越来越多的数据（用户历史记录、发票、交易......）。我们将所有这些都存储在 AWS dynamodb 数据库中，并且我们再次使用 socket-io 将 CRUD 操作从前端传递到后端。 我认为我们走错了方向。这是一个错误。

因为不久之后我们发现 Amazon 的云服务 (AWS) 为 RESTful 应用程序提供了一些出色的

负载平衡/扩展工具

。 我们现在的印象是，我们需要编写

大量代码来执行 CRUD 操作的握手

。 最近我们实施了 Paypal 集成。我们设法让它工作。但同样，

所有教程都使用 RESTful API 进行操作

。我们不得不重写/重新考虑他们的示例以使用 websocket 实现它们。我们让它工作得相当快。但确实感觉我们在

逆流而上。

说了这么多，我们下周就要上线了。我们及时到达那里，一切正常。 而且速度很快，但会扩展吗？

【讨论】：

只是想知道，当我们试图自己做出这个决定时，它是否可以很好地与 AWS 一起扩展？

@Gabe 显然节点可以轻松地在廉价的 aws 实例上获取 100 个 socket-io 连接。我们还没有注意到任何性能问题。奇怪的影响之一是，访问您的网站一次但随后在选项卡中打开网站的人继续使用连接。 （这经常发生在手机上）。所以，你至少需要一种机制来踢出空闲用户。不过，我还没有为此付出努力，因为我们的表现完全没有受到影响。 - 所以，还没有必要进行缩放。

同时，我们正在将 Node.js 代码迁移到 NestJS，同时我们正在重写所有身份验证代码。我们将混合使用 REST 和 websocket API。我们还将我们的应用程序拆分为更小的微服务，而这正是 NestJS 让我们的工作变得更容易的地方。

4 个月后，现在又重写了一切，使用 AWS 的 Cognito 和 Amplify 为我们做身份验证。 Amplify 和 Cognito 对社交帐户（google、facebook、...）登录有很好的支持。

【参考方案3】：

我会考虑使用both。每种技术都有其优点，没有一种万能的解决方案。

工作分离是这样进行的：

WebSockets 将是应用程序与需要会话的服务器通信的主要方法。这消除了旧浏览器所需的许多 hack（问题是对旧浏览器的支持将消除这种情况）

RESTful API 用于从浏览器缓存中受益的非面向会话（即不需要身份验证）的 GET 调用。一个很好的例子是 Web 应用程序使用的下拉列表的参考数据。然而。可以比...更频繁地更改...

html 和 javascript。这些组成了 webapp 的 UI。将这些放在 CDN 上通常会受益。

使用 WSDL 的 Web 服务仍然是 企业级 和跨企业通信的最佳方式，因为它为消息和数据传递提供了明确定义的标准。主要是将其卸载到 Datapower 设备以代理到您的 Web 服务处理程序。

所有这些都发生在 HTTP 协议上，该协议已经通过 SSL 提供了使用安全套接字。

但对于移动应用程序，websockets 无法重新连接到断开连接的会话 (How to reconnect to websocket after close connection) 并且管理它并非易事。所以对于移动应用程序，我仍然会推荐 REST API 和轮询。

在使用 WebSockets 与 REST 时要注意的另一件事是可扩展性。 WebSocket 会话仍由服务器管理。正确完成的 RESTful API 是无状态的（这意味着没有需要管理的服务器状态），因此可扩展性可以水平增长（这比垂直更便宜）。

【参考方案4】：

并不是说这里的其他答案没有优点，它们提出了一些好处。但是我将违背普遍的共识并同意你的观点，即转向 websockets 不仅仅是为了实时功能是非常有吸引力的。

我正在认真考虑通过 websockets 将我的应用程序从 RESTful 架构迁移到更多的 RPC 样式。这不是一个“玩具应用”，我说的不仅仅是实时功能，所以我有保留。但我看到走这条路有很多好处，并觉得它可能会成为一个特殊的解决方案。

我的计划是使用DNode、SocketIO 和Backbone。使用这些工具，我的 Backbone 模型和集合可以通过简单地调用 RPC 样式的函数在客户端和服务器之间传递。不再需要管理 REST 端点、序列化/反序列化对象等等。我还没有使用过 socketstream，但它看起来值得一试。

我还有很长的路要走，才能明确地说这是一个很好的解决方案，而且我确信它不是每个应用程序的最佳解决方案，但我相信这种组合会非常强大.我承认有一些缺点，比如失去缓存资源的能力。但我有一种感觉，优势将超过它们。

我有兴趣关注您探索此类解决方案的进展。如果你有任何 github 实验，请指点我。我还没有，但希望很快。

下面是我一直在收集的待读链接列表。我不能保证它们都是值得的，因为我只浏览了其中的许多。但希望有些人会有所帮助。

---

关于在 Express 中使用 Socket.IO 的精彩教程。它向 socket.io 公开了 express 会话，并讨论了如何为每个经过身份验证的用户提供不同的房间。

http://www.danielbaulig.de/socket-ioexpress/

关于 node.js/socket.io/backbone.js/express/connect/jade/redis 的教程，包括身份验证、Joyent 托管等：

http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/ http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

在 Backbone.js 中使用 Pusher 的教程（使用 Rails）：

http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

在客户端使用backbone.js 构建应用程序，在服务器上使用express、socket.io、dnode 构建node.js。

http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/ http://addyosmani.com/blog/building-spas-jquerys-best-friends/ http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/ http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

在 DNode 中使用 Backbone：

http://quickleft.com/blog/backbone-without-ajax-part-ii http://quickleft.com/blog/backbone-without-ajax-part-1 http://sorensen.posterous.com/introducing-backbone-redis https://github.com/cowboyrushforth/minespotter http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs http://hackerne.ws/item?id=2222935 http://substack.net/posts/24ab8c

【讨论】：

我刚刚回答了一个相关问题并提出了一些想法：***.com/questions/4848642/…

“我还有很长的路要走，才能明确地说这是一个好的解决方案” - 只是好奇，这真的是一个好的解决方案吗？ :D

请回复@Tauren。我对你现在要说的话很感兴趣。

@Tauren 我也很好奇这是怎么做到的？

现在是 2020 年，我也很好奇 :-)

【参考方案5】：

HTTP REST 和 WebSockets 非常不同。 HTTP 是无状态，因此 Web 服务器不需要知道任何内容，您可以在 Web 浏览器和代理中获得缓存。如果您使用 WebSockets，您的服务器将变为有状态，您需要与服务器上的客户端建立连接。

请求-回复通信与推送

仅当您需要 PUSH 数据从服务器到客户端时才使用 WebSockets，该通信模式不包含在 HTTP 中（仅通过变通方法）。如果其他客户端创建的事件需要对其他连接的客户端可用，则 PUSH 很有帮助，例如在用户应该根据其他客户行为采取行动的游戏中。或者，如果您的网站正在监控某些东西，服务器一直将数据推送到客户端，例如股票市场（实时）。

如果您不需要从服务器推送数据，则使用无状态 HTTP REST 服务器通常更容易。 HTTP 使用简单的Request-Reply 通信模式。

【讨论】：

我们非常习惯单向模式，因为我们之前从未有过任何替代方案。但现在，随着我的应用程序变得更加成熟，我越来越清楚地发现，使用推送技术的地方越多，响应速度越快，应用程序的参与度也越高。

我的应用会显示朋友列表，以及他们的积分数量。为什么不实时更新。如果用户可以看到他们的朋友在进步，那么他们可能更倾向于追赶。我有某些文档模型虽然没有经常更改，但更改得足够多，以至于不实时更新可能会引起轻微的混乱。在某些时候，您的网站有足够多的受益于推送更新，您开始查看代码，其中一半是关于 REST，另一半是关于套接字，你说得好，我想统一这一点。

这是一个仅使用 websocket 将通知/命令推送到您的 web 应用程序的选项（例如带有参数的 getUpdate 或 refreshObjectWithId）。可以在您的 webapp（客户端）中分析此命令，然后通过 rest 请求获取特定数据，而不是通过 websockets 传输数据本身。

websocket 比 REST 调用更容易的原因有很多——不仅仅是推送。 websocket.org/quantum.html

WebSockets 很神奇，它可以让服务器随时发送客户端数据，而不仅仅是响应客户端消息。 WebSockets 实现了基于消息的协议，因此客户端可以随时接收消息，如果他们正在等待特定消息，他们可以将其他消息排队以供稍后处理，重新排序排队的消息，根据应用程序状态忽略推送的消息等。永远不会再编写另一个基于 REST 的应用程序。 Flash 也很容易，它具有基于 AS3 的开源 WebSocket 实现，并通过 ExternalInterface.(addCallback/call) 方法回退到浏览器。

【参考方案6】：

我正在考虑为所有站点功能转换为 WebSocket api

没有。你不应该这样做。如果您同时支持这两种模型，则没有什么坏处。 REST 用于单向通信/简单请求，WebSocket 用于双向通信，尤其是当服务器要发送实时通知时。

WebSocket 是一种比 RESTful HTTP 更高效的协议，但在以下方面仍然 RESTful HTTP 得分高于 WebSocket。

已为 HTTP 很好地定义了创建/更新/删除资源。您必须在 WebSocket 的底层实现这些操作。

WebSocket 连接在单个服务器上垂直扩展，而 HTTP 连接水平扩展。 WebSocket 水平缩放有一些专有的非基于标准的解决方案。

HTTP 带有很多很好的功能，例如缓存、路由、多路复用、gzip 等。如果您选择 Websocket，这些功能必须构建在 Websocket 之上。

搜索引擎优化适用于 HTTP URL。

所有代理、DNS、防火墙尚未完全了解 WebSocket 流量。他们允许端口 80，但可能会通过先窥探端口来限制流量。

WebSocket 的安全性是孤注一掷的方法。

查看article 了解更多详情。

【讨论】：

这是最好的答案。

该主题的最佳答案

【参考方案7】：

我想要来自服务器的更新吗？

是：Socket.io 否：休息

Socket.io 的缺点是：

可扩展性：WebSockets 需要开放的连接和与 Web 规模大不相同的 Ops 设置。 Learnin：我没有无限的时间来学习。事情必须完成！

我仍将在我的项目中使用 Socket.io，但不适用于 REST 可以很好地完成的基本 Web 表单。

【参考方案8】：

基于 WebSockets（或长轮询）的传输主要用于服务器和客户端之间的（近）实时通信。尽管有许多场景需要此类传输，例如聊天或某种实时提要或其他内容，但并非某些 Web 应用程序的所有部分都需要与服务器双向连接。

REST 是一种基于资源的架构，它很容易理解，并且与其他架构相比具有自身优势。 WebSockets 更倾向于实时数据流/馈送，这将需要您创建某种基于服务器的逻辑，以便区分资源和馈送的优先级或区分（以防您不想使用 REST）。

我认为最终会有更多以 WebSockets 为中心的框架，例如 socketstream，届时这种传输将更加广泛，并且以数据类型/形式不可知交付的形式更好地理解/记录。但是，我认为，这并不意味着它会/应该取代 REST，因为它提供了许多用例和场景中不一定需要的功能。

【参考方案9】：

我可以使用 TCP (WebSockets) 作为主要 Web 内容交付策略的唯一问题是，关于如何使用 TCP 设计网站架构和基础设施的阅读材料非常少。

因此，您无法从其他人的错误中吸取教训，并且发展会变慢。这也不是一个“久经考验”的策略。

当然，您也会失去 HTTP 的所有优势（无状态和缓存是更大的优势）。

请记住，HTTP 是为提供 Web 内容而设计的 TCP 抽象。

我们不要忘记 SEO 和搜索引擎不做 websockets。所以你可以忘记 SEO。

我个人建议不要这样做，因为风险太大。

不要将 WS 用于服务网站，将其用于服务 Web 应用程序

但是，如果您有玩具或个人网站，请务必购买。尝试一下，走在最前沿。对于企业或公司，您无法证明这样做的风险是合理的。

【参考方案10】：

这不是一个好主意。该标准甚至还没有最终确定，支持因浏览器而异，等等。如果你现在想这样做，你最终需要回退到闪存或长轮询等。在未来它可能仍然不会做出很有意义，因为服务器必须支持向每个用户开放连接。大多数 Web 服务器被设计成擅长快速响应请求并尽快关闭它们。哎呀，甚至您的操作系统也必须进行调整以处理大量同时连接（每个连接使用更多的临时端口和内存）。尽可能多地在网站上使用 REST。

【讨论】：

是的，大多数网络服务器都擅长 HTTP。但是 node.js 不是一个 web 服务器，它是一个 io 库。它可以很好地执行 TCP。问题基本上是说我们可以设计网站来使用 TCP 而不是 HTTP。

同样的限制适用，你仍然会用尽临时端口/内存，它仍然会限制你可以同时服务的人数，并给系统带来不必要的负担。

是的，有一个限制，但如果您不为每个连接创建一个新线程，我认为这没什么大不了的。

我已经为每个用户准备了一个套接字。全球聊天 + 新闻源。

我想在 2011 年这是一个很棒的答案。 - 所以，我知道你来自哪里。但是在 2019 年，websockets 已经成熟了。