我应该将现有的Websocket连接用于请求/响应操作吗?
我正在设计一个游戏,该游戏利用Websocket进行实时沟通游戏动作和参与者之间的聊天。
我还需要客户进行元数据操作,例如:
- 创建一个新游戏表
- 获取当前游戏中的参与者
- 邀请其他用户
- 等。
我的问题是,这些操作是否在已经存在的WebSocket连接中进行,或者我应该在为他们创建REST API端点?
使用Websocket的优点是它已经打开,因此它将更快,并且我已经拥有了用户身份验证。
使用API的优点是所有这些操作都非常自然地要求/响应通信。我的意思是,如果我需要在Websocket中实施它,则该客户端将发出请求,并且响应将来(也许)的某个时候,我将不得不扫描套接字中的消息流并将每个响应分配给相应的请求手动。
我应该考虑其他任何观点,您对此有何看法?
I'm designing a game that makes use of websockets for realtime communication of game moves and chat between participants.
I also need clients to make metadata operations, such as:
- create a new game table
- get the list of participants in the current game
- invite other users
- etc.
My question is, should these operation be performed in the already existing websocket connection, or should I create REST API endpoints for them?
The advantage for using websockets is that it's already open, so it will be faster, and I have the user authentication already in place.
The advantage of using API is that all of these operations are very natural to request/response communication. I mean if I will need to implement it in websockets, that client will issue a request, and the response will come sometime in the future (maybe), and I will have to scan the stream of messages in the socket and assign each response to the corresponding request manually.
Any other points I should take into considerations, and what is your take on this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如罗伊·菲尔德(Roy Fielder)的论文中所述的休息,所提供的远远超过了请求/响应互动。但是大多数应用程序仅实现基本的get/put/post/delete/option http动词。从概念上讲,休息不限于通过HTTP实施。因此,Websockets可用于实现类似的协议。
我认为您意识到Websocket实际上是在HTTP顶部实现TCP的。因此,就网络基础架构而言,在HTTP缓存/代理机制上存在一些情况。
根据我在HTTP上休息的经验,如果您使用多个无关的起源,CORS可能是一个问题。取决于您的服务器的处理能力。
REST as described in Roy Fielder's dissertation provides far more than request/response interactions. But most applications only implement the basic GET/PUT/POST/DELETE/OPTION HTTP verbs. Conceptually REST is not limited to being implemented over HTTP. Thus WebSockets can be used to implement similar protocol.
I presume you realize that WebSockets is effectively an implementation of TCP on top of HTTP. So in terms of networking infrastructure, there are situations were REST over HTTP caching/proxing mechanisms are more performant.
In my experience with REST over HTTP, CORS can be an issue if you are using multiple unrelated origins. Depends on your server as to how well you can handle them.