Websocket API取代REST API？

Question

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

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

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

Answer 1

不是说这里的其他答案没有价值,他们提出了一些好处.但是我会违背普遍的共识并同意你的观点,即移动到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

Answer 2

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

请求 - 回复通信与推送

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

如果您不需要从服务器推送数据,则通常更容易使用无状态HTTP REST服务器.HTTP使用简单的请求 - 回复通信模式.

Answer 3

我正在考虑转换到所有站点功能的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的安全性是全有或全无的方法.

有关更多详细信息,请查看此文章.

Answer 4

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

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

当然,你也会失去HTTP的所有优点(无状态,缓存是更大的优势).

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

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

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

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

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

Answer 5

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

它从概念验证开始，效果很好。但是当我们想让公众使用它时，我们不得不添加用户会话，所以我们需要登录功能。不管你怎么看，websocket 都必须知道它处理的是哪个用户，所以我们采取了使用 websockets 来验证用户的捷径。这看起来很明显，而且很方便。

我们实际上不得不安静一些时间以使连接可​​靠。我们从一些廉价的 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 来完成的。我们不得不重写/重新思考他们的例子，用 websockets 来实现它们。不过，我们让它运行得相当快。但确实感觉我们在逆流而上。

说了这么多，我们下周就要直播了。我们及时到达那里，一切正常。它很快，但它会扩展吗？

Answer 6

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

工作的分离是这样的：

1. WebSockets将是应用程序与需要会话的服务器进行通信的主要方法。这消除了旧浏览器所需的许多黑客攻击（问题是对旧浏览器的支持将消除这一点）

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

3. HTML 和 JavaScript。这些构成了 webapp 的 UI。这些通常会有益于放置在 CDN 上。

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

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

但是，对于移动应用程序，websockets 无法重新连接到断开连接的会话（如何在关闭连接后重新连接到 websocket）并且管理这不是微不足道的。因此，对于移动应用程序，我仍然会推荐 REST API和轮询。

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