Websocket API取代REST API？

Posted 2021-03-27

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

但是，大多数站点都是以RESTful方式编写的，这对于应用程序和其他客户来说非常好。但是，我正在考虑转换到所有站点功能的websocket API，远离REST。这样我就可以更轻松地将实时功能集成到网站的所有部分。这会使构建应用程序或移动客户端变得更加困难吗？

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

答案

不是说这里的其他答案没有价值，他们提出了一些好处。但是我会违背普遍的共识并同意你的观点，即移动到websockets而不仅仅是实时功能是非常有吸引力的。

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

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

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

我有兴趣跟踪您在探索此类解决方案方面取得的进展。如果您有任何github实验，请指出我。我还没有，但希望很快。

以下是我一直在收集的以后阅读链接的列表。我不能保证他们都是值得的，因为我只是撇去了其中许多人。但希望有些人会有所帮助。

---

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

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

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

• 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/

使用Pusher和Backbone.js的教程（使用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

另一答案

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

Request-Reply communication vs Push

仅当您需要从服务器到客户端的PUSH数据时才使用WebSockets，该通信模式不包含在HTTP中（仅通过解决方法）。如果由其他客户端创建的事件需要可用于其他连接的客户端，则PUSH是有用的，例如在用户应该对其他客户行为采取行动的游戏中。或者，如果您的网站正在监控某些内容，那么服务器会始终将数据推送到客户端，例如：股票市场（现场）。

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

另一答案

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

不，你不应该这样做。如果您支持这两种型号，则没有任何危害。使用REST进行单向通信/简单请求和WebSocket进行双向通信，尤其是当服务器想要发送实时通知时。

WebSocket是一种比RESTful HTTP更有效的协议，但在以下区域仍然是基于WebSocket的RESTful HTTP分数。

1. 已为HTTP定义了创建/更新/删除资源。您必须在WebSockets的低级别实现这些操作。
2. WebSocket连接在单个服务器上垂直扩展，HTTP连接水平扩展。 WebSocket水平扩展有一些专有的非基于标准的解决方案。
3. HTTP带有很多很好的功能，如缓存，路由，多路复用，gzipping等。如果选择Websocket，这些功能必须建立在Websocket之上。
4. 搜索引擎优化适用于HTTP URL。
5. 所有代理，DNS，防火墙尚未完全了解WebSocket流量。它们允许端口80，但可能首先通过窥探来限制流量。
6. WebSocket的安全性是全有或全无的方法。

有关更多详细信息，请查看此article。

另一答案

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

所以你无法从别人的错误中吸取教训，发展也会变慢。它也不是一个“久经考验”的策略。

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

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

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

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

不要使用WS来提供网站服务，使用它来提供网络应用程序

但是，如果你有玩具或个人网站，一定要去。尝试一下，做到最前沿。对于企业或公司而言，您无法证明这样做的风险。

另一答案

我会考虑同时使用两者。每项技术都有其优点，并没有一刀切的解决方案。

工作分离是这样的：

1. WebSockets是应用程序与需要会话的服务器通信的主要方法。这消除了旧浏览器所需的许多黑客攻击（问题是支持旧浏览器，这将消除这一点）
2. RESTful API用于GET调用，这些调用不是面向会话（即不需要身份验证），而是受益于浏览器缓存。一个很好的例子就是Web应用程序使用的下拉参考数据。然而。比......更能改变一下
3. html和javascript。这些包括webapp的UI。这些通常有利于放在CDN上。
4. 使用WSDL的Web服务仍然是企业级和跨企业通信的最佳方式，因为它为消息和数据传递提供了明确定义的标准。主要是您将其卸载到Datapower设备以代理您的Web服务处理程序。

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

但是对于移动应用程序，websockets无法重新连接回断开的会话（How to reconnect to websocket after close connection）并且管理这不是一件容易的事。因此，对于移动应用程序，我仍然会推荐REST API和轮询。

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

另一答案

我想要从服务器更新吗？

• 是的：Socket.io
• 没有休息

Socket.io的缺点是：

• 可伸缩性：WebSockets需要开放式连接和大规模不同的Ops设置。
• 学习：我没有无限的时间学习。事情必须要完成！

我仍然会在我的项目中使用Socket.io，但不会使用REST可以很好地使用的基本Web表单。

另一答案

我学到了一点教训（艰难的方法）。我制作了一个运行在Ubuntu AWS EC2云服务上的数字运算应用程序（使用功能强大的GPU），我想为它做一个前端，只是为了实时观察它的进展。由于它需要实时数据，显然我需要websockets来推送更新。

它始于概念验证，并且运作良好。但是当我们想让公众可以使用它时，我们必须添加用户会话，因此我们需要登录功能。无论你如何看待它，websocket都必须知道它处理的是哪个用户，因此我们采用了使用websockets来验证用户的快捷方式。这看起来很明显，很方便。

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

说了这么多，说实话，我认为我们错过了一些很棒的socket-io功能。 Socket-io还有很多东西可以提供，我相信，如果你在初始设计中考虑它，你可以从中获得更多。相比之下，我们只是用socket-io的websocket功能替换旧的websockets，就是这样。 （没有房间，没有频道......）重新设计可以让一切变得更加强大。但我们没有时间。这是我们下一个项目要记住的事情。

接下来，我们开始存储越来越多的数据（用户历史记录，发票，交易......）。我们将所有这些存储在AWS dynamodb数据库中，而AGAIN，我们使用socket-io将CRUD操作从前端