我计划一个非平凡的实时聊天平台。该应用程序有几种类型的资源：用户，组，频道，消息。大约有20种类型的实时事件与这些资源有关：例如，提交消息，用户连接或断开连接，用户加入组，主持人从组中踢出用户等等......
总的来说，我看到了组织所有这些复杂性的两条路径。
首先是构建REST API来管理资源。例如，要发送消息，请POST到/api/v1/messages。或者，要从组中踢出用户，请POST到/api/v1/group/:group_id/kick/。然后，从Express路由处理程序中，使用更新的数据调用io.emit（通过res.locals可访问）以通知所有相关客户端。在这种情况下，客户端通过HTTP与服务器通信，服务器通过socket.io通知客户端。
另一个选择是根本没有rest API，并通过socket.IO处理所有事件。例如，要发送消息，请发出SEND_MESSAGE事件。或者，为了踢用户，发出KICK_USER事件。然后，在socket.io事件处理程序中，使用更新的数据调用io.emit以通知所有客户端。
另一种选择是让REST API处理某些操作，其他选项由socket.IO处理。例如，要获取所有消息GET api/v1/channel/:id/messages。但要发布消息，请向套接字发出SEND_MESSAGE。
哪种选择最合适？如何确定需要通过API发送哪些操作，哪些需要通过socket.io发送？最好不要为这种类型的应用程序提供REST API吗？
到目前为止我的一些想法，没有结论：
REST API相对于socket.io-only方法的优点：
更容易组织分层，更模块化
更容易测试
更健壮，更优雅
使用中间件实现更简单的身份验证
REST API的缺点而不是socket.io-only方法：
性能稍差（source）
由于套接字连接需要打开，为什么不将它用于一切？
在客户端管理稍微困难。
感谢阅读！
答案 0 :(得分：1)
这可以使用套接字来实现。
为什么因为聊天应用程序会有许多操作，例如..
'STARTS_TYPING'，'STOPS_TYPING'，'SEND_MESSAGE'，'RECIVE_MESSAGE'，...
使用rest api来适应所有这些功能将产生一个缺乏性能的复杂系统。
socket.io中的房间概念也简化了群聊实施的难题。
因此，最好根据套接字[socket.io或web cluster]构建所有内容。
答案 1 :(得分：0)
以下是我发现解决此问题的解决方案。
我的问题中的关键错误是我假设一个rest API和websockets是互斥的，因为我打算直接在快速路由和socket.io处理程序中集成业务和数据库逻辑。因此，在socket.io和http之间进行选择很重要，因为它会影响我的应用程序的核心业务逻辑。
相反，使用哪种传输并不重要。业务逻辑必须独立于传输逻辑，在其自己的模块中。
为此，我开发了一个处理CRUD任务的服务层，还开发了更具体的任务，如身份验证。然后，可以从快速路由和socket.io处理程序之一或两者中轻松地使用此服务层。
最后，这种架构使我不必在传输技术之间轻松切换。