用Websocket API取代REST API？

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

但是，大多数网站是以REST风格编写的，这对于将来的应用程序和其他客户来说是很好的。 不过，我正在考虑从REST转移到所有网站function的websocket API。 这将使我更容易将实时function集成到网站的所有部分。 这会使得构build应用程序或移动客户端变得更加困难吗？

我发现有些人已经在做这样的东西： SocketStream

Answer 1

不是说这里的其他答案没有价值，他们提出了一些好的观点。 但是我要违背普遍的共识，并且同意你的观点，转向websockets不仅仅是实时特性，这是非常有吸引力的。

我正在认真考虑通过websockets将我的应用程序从RESTful体系结构转移到更多的RPC体系。 这不是一个“玩具应用程序”，我不是只谈论实时function，所以我有保留。 但是，我认为走这条路可以带来很多好处，并觉得这可能是一个非常好的解决scheme。

我的计划是使用DNode ， SocketIO和Backbone 。 有了这些工具，我的Backbone模型和集合可以通过调用一个函数RPC风格来传递给客户端和服务器。 没有更多的pipe理REST端点，序列化/反序列化对象，等等。 我还没有使用socketstream，但它看起来值得检查。

在我可以明确地说这是一个好的解决scheme之前，我还有很长的路要走，我相信这不是每个应用程序的最佳解决scheme，但是我相信这个组合将是非常强大的。 我承认有一些缺点，比如失去了caching资源的能力。 但我有一个感觉，优势将超过他们。

我有兴趣跟随你的进展，探索这种types的解决scheme。 如果你有任何github实验，请指点他们。 我还没有，但希望很快。

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

---

有关Express使用Socket.IO的很好的教程。 它向socket.io公开快速会话，并讨论如何为每个经过身份validation的用户拥有不同的房间。

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

Node.js / socket.io / backbone.js / express / connect / jade / redis with authentication，Joyent hosting等教程：

• 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和node.js与服务器上的express，socket.io，dnode构build应用程序。

• 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一起使用主干：

• 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浏览器和代理中获取caching。 如果您使用WebSockets，您的服务器变得有状态 ，您需要连接到服务器上的客户端。

请求 – 应答通信与推送

只有在需要将数据从服务器推送到客户端时，才使用WebSockets，HTTP中不包含该通信模式（仅用于解决方法）。 如果其他客户端创build的事件需要对其他连接的客户端可用，例如在用户应该根据其他客户端行为进行操作的游戏中，则PUSH非常有用。 或者，如果您的网站正在监控某些事情，那么服务器就会一直向客户端推送数据，例如股市（现场）。

如果您不需要从服务器上压入数据，使用无状态的HTTP REST服务器通常会更容易。 HTTP使用简单的请求 – 应答通信模式。

Answer 3

我正在考虑过渡到所有网站function的WebSocket API

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

WebSocket是一个比RESTful HTTP更有效的协议，但仍然在下面的区域使用WebSocket的RESTful HTTP分数。

1. 创build/更新/删除资源已经很好地定义了HTTP。 您必须在WebSockets的低级别执行这些操作。

2. WebSocket连接在HTTP连接水平伸缩的单个服务器上垂直伸缩。 有一些专有的非标准的WebSocket水平缩放解决scheme。

3. HTTP带有很多好的function，如caching，路由，复用，gzipping等。如果你selectWebsocket的话，这些必须build立在Websocket之上。

4. search引擎优化适用于HTTPurl。

5. 所有代理，DNS，防火墙还不完全知道WebSocketstream量。 他们允许端口80，但可能会通过先窥探它来限制stream量。

6. WebSocket的安全性是全有或全无的方法。

看看这篇文章的更多细节。

Answer 4

我可以使用TCP（WebSockets）作为您的主要networking内容交付策略的唯一问题是，关于如何使用TCPdevise您的网站架构和基础架构的读物很less。

所以你不能从别人的错误中学习，发展会变慢。 这也不是一个“经过validation的”策略。

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

请记住，HTTP是用于为Web内容提供服务的TCP的抽象。

我们不要忘记，search引擎优化和search引擎不会做websocket。 所以你可以忘记SEO。

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

不要使用WS来为网站提供服务，而是使用它来提供Web应用程序

但是，如果你有一个玩具或个人网站的一切手段去为它。 尝试一下，成为前沿。 对于一个企业或公司，你不能certificate这样做的风险。

Answer 5

我会考虑使用两个。 每项技术都有其优点，而且没有一个适合所有的解决scheme。

工作的分离是这样的：

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

2）RESTful API用于不受会话导向的GET调用（即，不需要authentication），从浏览器caching中受益。 一个很好的例子就是Web应用程序使用的下拉列表的参考数据。 然而。 可以改变一点比…

3）HTML和Javascript。 这些包括webapp的UI。 这些通常有利于放在CDN上。

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

所有这一切都发生在HTTP协议上，通过SSL使用安全套接字。

但是，对于移动应用程序来说，websockets不能重新连接到断开连接的会话（ closures连接后如何重新连接到websocket ），并且pipe理这些并不重要。 所以对于移动应用程序，我仍然会推荐REST API和轮询。

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

Answer 6

基于WebSocket（或长轮询）的传输主要用于（近）服务器和客户端之间的实时通信。 虽然有很多这种types的传输是必需的，比如聊天或者某种types的实时传输或者其他东西，但是并不是所有的Web应用程序的所有部分都需要与服务器双向连接。

REST是基于资源的架构，它是很好理解的，并提供它自己的优势，超过其他架构。 WebSockets更倾向于实时的数据stream/数据源，这需要您创build某种基于服务器的逻辑，以优先考虑或区分资源和提要（如果您不想使用REST）。

我假设未来将会有更多像WebSocket一样的中心框架，比如socketstream ，这种传输方式将会以数据types/表单不可知的forms更好地被理解/logging。 然而，我认为，这并不意味着它会/应该替代REST，因为它提供了在许多用例和场景中不一定需要的function。

Answer 7

我想从服务器更新吗？

• 是的：Socket.io
• 没有rest

Socket.io的缺点是：

• 可扩展性：WebSockets需要开放的连接和一个非常不同的Ops设置到networking规模。
• 学习：我没有无限的时间来学习。 事情必须完成！

我仍然会在我的项目中使用Socket.io，但是对于REST将很好地处理的基本Web表单。

Answer 8

这不是一个好主意。 该标准甚至还没有最终确定，不同的浏览器支持不同，如果你想这样做，现在你最终将需要回退到闪光灯或长时间轮询，等等在将来它可能仍然不会很有道理，因为服务器必须支持将连接开放给每个用户。 大多数Web服务器被devise成能够快速响应请求并尽可能快地closures它们。 甚至你的操作系统将不得不被调整来处理大量的同时连接（每个连接使用更多的临时端口和内存）。 坚持尽可能多地使用REST。