Websocket API将取代REST API？
我有一个应用程序，它的主要功能是通过websockets或长轮询实时工作的。
但是，该站点的大部分内容都是以RESTful方式编写的，这对于将来的应用程序和其他客户端来说很好。然而，我正在考虑为所有站点功能过渡到websocket API，而不是REST。这将使我更容易将实时功能集成到网站的所有部分。这会使构建应用程序或移动客户端变得更加困难吗？
我发现有些人已经在做这样的事情：SocketStream
回答 2
Stack Overflow用户
发布于 2011-07-24 19:19:36
基于WebSockets (或长轮询)的传输主要用于(接近)服务器和客户端之间的实时通信。尽管有许多场景需要这些类型的传输，例如聊天或某种实时馈送或其他东西，但并不是某些web应用程序的所有部分都必须与服务器双向连接。
REST是一种基于资源的架构，它很容易理解，并提供了比其他架构更好的优势。WebSockets更倾向于实时的数据流/馈送，这将需要您创建某种基于服务器的逻辑，以便区分资源和馈送之间的优先级或区别(如果您不想使用REST)。
我假设将来最终会有更多像socketstream这样的以WebSockets为中心的框架，那时这种传输将更加广泛，并以数据类型/形式不可知的交付的形式更好地被理解/记录。然而，我认为，这并不意味着它会/应该取代其余的功能，因为它提供了在许多用例和场景中不一定需要的功能。
Stack Overflow用户
发布于 2011-07-24 18:40:42
这不是个好主意。这个标准甚至还没有定稿，支持在不同的浏览器上有所不同，等等。如果你现在想这样做，你最终将需要退回到flash或长轮询等。在未来，它可能仍然没有多大意义，因为服务器必须支持让连接对每个单独的用户开放。相反，大多数web服务器都被设计为擅长快速响应请求并尽可能快地关闭它们。见鬼，即使是你的操作系统也必须调优，以处理大量的同时连接(每个连接使用更多的临时端口和内存)。在站点中尽可能多地使用REST。
https://stackoverflow.com/questions/6806263
复制相似问题
腾讯云开发者
