API的Websocket理论

Cha*_*tte 0 api-design websocket

我在服务器上运行一个API,该API处理用户连接和消息传递系统。

除此之外,我还在同一台服务器上启动了一个websocket,等待连接和其他东西。

假设我们可以通过Android应用访问此功能。

我很难弄清楚现在应该做什么,这是我的想法:

1-当用户连接到应用程序时,API将连接到websocket。我们仅允许Android应用在此套接字上侦听以获取新消息。当用户想要回答时,Android应用会将消息发送到API。API将接收到的消息本身写入套接字,该消息将由另一个用户使用的Android应用读取。这样,API可以在将消息写入套接字之前将消息存储在数据库中。

2- API不会以任何方式连接到websocket。Android应用程序会在需要时侦听并写入Websocket,并且在写入Websocket时也应向API发送请求,以便可以将消息存储在DB中。

可能以上都不正确,请让我知道

编辑

我已经理解了为什么我应该使用websocket,这似乎是拥有这种“实时”系统的最佳方法(例如,在收到新消息时),而不是强制客户端每隔x秒发出一次HTTP请求以检查是否存在是新邮件。

我仍然不了解的是,如何与我的数据库进行通信。抱歉,如果我的示例不清楚,但我将尝试继续进行下去:

我的消息传递系统需要将所有消息存储在我的API数据库中,以具有某种对话的历史记录。

但是似乎websocket必须与API分开运行,我的意思是这是另一个程序,对吗?因为它不是针对HTTP请求的

那么,API是否也应该侦听此网络套接字以捕获新消息并存储它们?

jfr*_*d00 5

您确实没有描述应用程序的要求,因此我们很难直接建议您的应用程序应该做什么。您真的不应该以说您拥有一个webSocket来开始您的分析,而您正在尝试弄清楚该怎么做。取而代之的是,列出应用程序的要求,然后找出最能满足这些要求的技术。

由于您的要求不清楚,因此,我将讨论最适合使用webSocket以及最适合使用更传统的http请求。

这是webSocket的一些特征:

  1. 它被设计为在更长的持续时间内(比客户端和服务器之间的一次交换的持续时间更长)进行持续连接。
  2. 通常从客户端到服务器建立连接。
  3. 建立连接后,就可以随时从客户端到服务器或从服务器到客户端向任一方向发送数据。这与典型的http请求(后者只能由客户端请求数据)有很大的不同-使用http请求,服务器无法启动向客户端的数据发送。
  4. 默认情况下,webSocket不是请求/响应体系结构。实际上,要使其像请求/响应一样工作,需要在webSocket协议之上构建一个层,以便您可以知道哪个响应与哪个请求一起进行。http是本地请求/响应。
  5. 因为webSocket被设计为连续连接(或至少在一段时间内保持连接),所以它在两个端点之间频繁通信的情况下可以很好地工作(并且开销较低)。连接已经建立,并且可以直接发送数据而没有任何连接建立开销。另外,与使用http相比,使用webSocket的每条消息的开销通常较小。

因此,有两个典型的原因使您可能选择其中一个。

  1. 如果您需要能够从服务器向客户端发送数据而无需客户端定期轮询新数据,则webSocket就是为此而精心设计的,http无法做到这一点。
  2. 如果您经常发送大量的少量数据(例如,温度探测器每10秒发送一次当前温度),则与为每个新的数据段发起新的http请求相比,webSocket会减少网络和服务器的开销。
  3. 如果您没有以上任何一种情况,那么您可能根本不需要webSocket,并且http请求/响应模型可能更简单。
  4. 如果您确实需要将特定响应绑定到特定请求的请求/响应,则该请求/响应内置于http中,而不是webSockets的内置功能。

您可能还会发现这些其他有用的帖子:

使用Websockets代替RESTful HTTP有什么陷阱?

WebSocket和普通套接字通信之间有什么区别?

推送通知| websocket是强制性的吗?

WebSockets服务器架构如何工作?

回应您的编辑

但是似乎websocket必须与API分开运行,我的意思是这是另一个程序,对吗?因为它不是针对HTTP请求的

支持API的相同过程也可以提供webSocket连接。因此,当您在webSocket上获取传入数据时,只需将其直接写入数据库即可,就像API访问数据库一样。因此,不需要webSocket服务器不必是单独的程序或进程。

那么,API是否也应该侦听此网络套接字以捕获新消息并存储它们?

不,我不这么认为。只有一个进程可以监听一组传入的webSocket连接。