我有一个应用程序,其主要功能是通过websockets或长轮询实时工作。
但是,大多数站点都是以RESTful方式编写的,这对于应用程序和其他客户来说非常好。但是,我正在考虑转换到所有站点功能的websocket API,远离REST。这样我就可以更轻松地将实时功能集成到网站的所有部分。这会使构建应用程序或移动客户端变得更加困难吗?
我发现有些人已经在做这样的事情:SocketStream
不是说这里的其他答案没有价值,他们提出了一些好处。但是我会违背普遍的共识并同意你的观点,即移动到websockets而不仅仅是实时功能是非常有吸引力的。
我正在认真考虑通过websockets将我的应用程序从RESTful架构转移到更多RPC样式。这不是一个“玩具应用程序”,我不是只讨论实时功能,所以我确实有所保留。但是我认为这条路线有很多好处,并且觉得它可能会成为一种特殊的解决方案。
我的计划是使用DNode,SocketIO和Backbone。使用这些工具,我的Backbone模型和集合可以通过简单地调用函数RPC样式从/向客户端和服务器传递。不再需要管理REST端点,序列化/反序列化对象等等。我还没有使用socketstream,但看起来值得一试。
我还有很长的路要走,才能明确地说这是一个很好的解决方案,而且我确信它不是每个应用程序的最佳解决方案,但我确信这种组合会非常强大。我承认存在一些缺点,例如失去缓存资源的能力。但我觉得优势将超过他们。
我有兴趣跟踪您在探索此类解决方案方面取得的进展。如果您有任何github实验,请指出我。我还没有,但希望很快。
以下是我一直在收集的以后阅读链接的列表。我不能保证他们都是值得的,因为我只是撇去了其中许多人。但希望有些人会有所帮助。
关于在Express中使用Socket.IO的精彩教程。它向socket.io公开了快速会话,并讨论了如何为每个经过身份验证的用户提供不同的会议室。
有关身份验证,Joyent托管等的node.js / socket.io / backbone.js / express / connect / jade / redis教程:
使用Pusher和Backbone.js的教程(使用Rails):
在客户端上使用backbone.js构建应用程序,在服务器上使用express,socket.io,dnode构建node.js。
使用带有DNode的Backbone:
HTTP REST和WebSockets非常不同。 HTTP是无状态的,因此Web服务器不需要知道任何内容,您可以在Web浏览器和代理中进行缓存。如果使用WebSockets,则服务器将变为有状态,并且您需要与服务器上的客户端建立连接。
仅当您需要从服务器到客户端的PUSH数据时才使用WebSockets,该通信模式不包含在HTTP中(仅通过解决方法)。如果由其他客户端创建的事件需要可用于其他连接的客户端,则PUSH是有用的,例如在用户应该对其他客户行为采取行动的游戏中。或者,如果您的网站正在监控某些内容,那么服务器会始终将数据推送到客户端,例如:股票市场(现场)。
如果您不需要从服务器推送数据,则通常更容易使用无状态HTTP REST服务器。 HTTP使用简单的Request-Reply通信模式。
我正在考虑转换到所有站点功能的WebSocket api
不,你不应该这样做。如果您支持这两种型号,则没有任何危害。使用REST进行单向通信/简单请求和WebSocket进行双向通信,尤其是当服务器想要发送实时通知时。
WebSocket是一种比RESTful HTTP更有效的协议,但在以下区域仍然是基于WebSocket的RESTful HTTP分数。
有关更多详细信息,请查看此article。
我可以使用TCP(WebSockets)作为主要Web内容交付策略的唯一问题是,关于如何使用TCP设计网站架构和基础架构的阅读材料非常少。
所以你无法从别人的错误中吸取教训,发展也会变慢。它也不是一个“久经考验”的策略。
当然,你也会失去HTTP的所有优点(无状态,缓存是更大的优势)。
请记住,HTTP是TCP的抽象设计,用于提供Web内容。
让我们不要忘记SEO和搜索引擎不做websockets。所以你可以忘记SEO。
我个人建议不要这样做,因为风险太大。
不要使用WS来提供网站服务,使用它来提供网络应用程序
但是,如果你有玩具或个人网站,一定要去。尝试一下,做到最前沿。对于企业或公司而言,您无法证明这样做的风险。
我会考虑同时使用两者。每项技术都有其优点,并没有一刀切的解决方案。
工作分离是这样的:
所有这些都发生在HTTP协议上,它已经通过SSL提供了使用安全套接字。
但是对于移动应用程序,websockets无法重新连接回断开的会话(How to reconnect to websocket after close connection)并且管理这不是一件容易的事。因此,对于移动应用程序,我仍然会推荐REST API和轮询。
使用WebSockets和REST时需要注意的另一件事是可伸缩性。 WebSocket会话仍由服务器管理。 RESTful API在正确完成时是无状态的(这意味着没有需要管理的服务器状态),因此可伸缩性可以水平增长(这比垂直更便宜)。
我想要从服务器更新吗?
Socket.io的缺点是:
我仍然会在我的项目中使用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操作从前端传递到后端。我想我们在那里走错了路。那是一个错误。
说了这么多,我们下周就要上线了。我们及时到达那里,一切正常。它很快,但会扩展吗?
基于WebSockets(或长轮询)的传输主要用于服务器和客户端之间的(近)实时通信。虽然有许多场景需要这些类型的传输,例如聊天或某种实时源或其他东西,但并非某些Web应用程序的所有部分都必须与服务器双向连接。
REST是基于资源的体系结构,它易于理解,并且与其他体系结构相比具有自身的优势。 WebSockets实时倾向于数据流/数据源,这需要您创建某种基于服务器的逻辑,以便对资源和提要进行优先级排序或区分(如果您不想使用REST)。
我假设最终将会有更多像Web引脚的中心框架,如socketstream,这种传输将更加广泛,并以数据类型/形式不可知传递的形式更好地理解/记录。但是,我认为,这并不意味着它会/应该替换REST只是因为它提供的功能在许多用例和场景中不一定是必需的。
那不是个好主意。该标准尚未最终确定,支持因浏览器等而异。如果您现在想要这样做,您最终将需要回退到闪存或长时间轮询等。将来它可能仍然不会很有意义,因为服务器必须支持让每个用户都能打开连接。大多数Web服务器的设计都是为了快速响应请求并尽可能快地关闭它们。甚至你的操作系统也必须经过调整才能处理大量的同时连接(每个连接使用更多短暂的端口和内存)。坚持尽可能多地使用REST作为网站。