API 的 websockets 理论
The theory of websockets with API
我在服务器上有一个 API 运行，它处理用户连接和消息系统。
除此之外，我在同一台服务器上启动了一个 websocket，等待连接和其他东西。
假设我们可以通过 Android 应用访问它。
我很难弄清楚我现在应该做什么，这是我的想法：
1 - 当用户连接到应用程序时，API 连接到 websocket。我们只允许 Android 应用程序在此套接字上侦听以获取新消息。当用户想要回答时，Android 应用程序会向 API 发送一条消息。 API 将自己收到的消息写入套接字，该套接字将由另一个用户使用的 Android 应用程序读回。
这样，API 可以在将消息写入套接字之前将消息存储在数据库中。
2- API 不以任何方式连接到 websocket。 Android 应用程序在需要时监听和写入 websocket，并且在写入 websocket 时，还应该向 API 发送请求，以便它可以将消息存储在数据库中。
可能none以上是正确的，请告诉我
编辑
我已经明白为什么我应该使用 websocket，这似乎是拥有这个 "real time" 系统的最佳方式（例如，当收到一条新消息时），而不是强制客户端每次都发出 HTTP 请求x 秒检查是否有新消息。
我仍然不明白的是，它应该如何与我的数据库通信。很抱歉，如果我的示例不清楚，但我会继续努力：
我的消息系统需要将所有消息存储在我的 API 数据库中，以便对对话进行某种历史记录。
但似乎 websocket 必须 运行 与 API 分开，我的意思是它是另一个程序，对吗？因为它不适用于 HTTP 请求
那么 API 是否也应该监听此 websocket 以捕获新消息并存储它们？
您确实没有描述您的应用程序的要求，因此我们很难直接建议您的应用程序应该做什么。你真的不应该通过说你有一个 webSocket 来开始你的分析，然后你试图弄清楚如何处理它。相反，列出您的应用程序的要求并找出最能满足这些要求的技术。
既然你的需求不清楚，那我就说说webSocket最好用在什么地方，比较传统的http请求最好用在什么地方。
以下是 webSocket 的一些特征：
- 它被设计为在更长的时间内连续连接（比客户端和服务器之间一次交换的持续时间长得多）。
- 连接通常是从客户端到服务器。
- 连接建立后，数据可以随时从客户端发送到服务器或从服务器发送到客户端。这与典型的 http 请求有很大的不同，在典型的 http 请求中，数据只能由客户端请求 - 对于 http 请求，服务器无法启动向客户端发送数据。
- 默认情况下，webSocket 不是 request/response 架构。事实上，要使其像 request/response 一样工作，需要在 webSocket 协议之上构建一个层，以便您可以判断哪个响应与哪个请求对应。 http 本身是 request/response.
- 因为 webSocket 被设计为持续连接（或至少连接一段时间），所以它在两个端点之间频繁通信的情况下工作得很好（并且开销较低）。连接已经建立，可以直接发送数据而无需任何连接建立开销。此外，webSocket 每条消息的开销通常比 http 小。
所以，这里有几个典型的原因，您可能会选择一个而不是另一个。
- 如果您需要能够从服务器向客户端发送数据而无需客户端定期轮询新数据，那么 webSocket 设计得非常好，而 http 无法做到这一点。
- 如果您经常发送大量小数据（例如，温度探测器每 10 秒发送一次当前温度），则 webSocket 比每隔新数据。
- 如果您没有上述任何一种情况，那么您可能真的不需要 webSocket，http request/response 模型可能会更简单。
- 如果您确实需要 request/response 将特定响应绑定到特定请求，那么它内置于 http 而不是 webSockets 的内置功能。
您可能还会发现这些其他帖子有用：
Push notification | is websocket mandatory?
How does WebSockets server architecture work?
对您的编辑的回应
But it seems like a websocket must be running separately from the API,
I mean it's another program right? Because it's not for HTTP requests
支持您的 API 的同一进程也可以为 webSocket 连接提供服务。因此，当您在 webSocket 上获取传入数据时，您可以直接将其写入数据库，就像 API 访问数据库一样。所以，不，webSocket 服务器不必是一个单独的程序或进程。
So should the API also listen to this websocket to catch new messages
and store them?
不，我不这么认为。只有一个进程可以侦听一组传入的 webSocket 连接。
我在服务器上有一个 API 运行，它处理用户连接和消息系统。
除此之外，我在同一台服务器上启动了一个 websocket，等待连接和其他东西。
假设我们可以通过 Android 应用访问它。
我很难弄清楚我现在应该做什么，这是我的想法：
1 - 当用户连接到应用程序时，API 连接到 websocket。我们只允许 Android 应用程序在此套接字上侦听以获取新消息。当用户想要回答时，Android 应用程序会向 API 发送一条消息。 API 将自己收到的消息写入套接字，该套接字将由另一个用户使用的 Android 应用程序读回。 这样，API 可以在将消息写入套接字之前将消息存储在数据库中。
2- API 不以任何方式连接到 websocket。 Android 应用程序在需要时监听和写入 websocket，并且在写入 websocket 时，还应该向 API 发送请求，以便它可以将消息存储在数据库中。
可能none以上是正确的，请告诉我
编辑
我已经明白为什么我应该使用 websocket，这似乎是拥有这个 "real time" 系统的最佳方式（例如，当收到一条新消息时），而不是强制客户端每次都发出 HTTP 请求x 秒检查是否有新消息。
我仍然不明白的是，它应该如何与我的数据库通信。很抱歉，如果我的示例不清楚，但我会继续努力：
我的消息系统需要将所有消息存储在我的 API 数据库中，以便对对话进行某种历史记录。
但似乎 websocket 必须 运行 与 API 分开，我的意思是它是另一个程序，对吗？因为它不适用于 HTTP 请求
那么 API 是否也应该监听此 websocket 以捕获新消息并存储它们？
您确实没有描述您的应用程序的要求，因此我们很难直接建议您的应用程序应该做什么。你真的不应该通过说你有一个 webSocket 来开始你的分析，然后你试图弄清楚如何处理它。相反，列出您的应用程序的要求并找出最能满足这些要求的技术。
既然你的需求不清楚，那我就说说webSocket最好用在什么地方，比较传统的http请求最好用在什么地方。
以下是 webSocket 的一些特征：
- 它被设计为在更长的时间内连续连接（比客户端和服务器之间一次交换的持续时间长得多）。
- 连接通常是从客户端到服务器。
- 连接建立后，数据可以随时从客户端发送到服务器或从服务器发送到客户端。这与典型的 http 请求有很大的不同，在典型的 http 请求中，数据只能由客户端请求 - 对于 http 请求，服务器无法启动向客户端发送数据。
- 默认情况下，webSocket 不是 request/response 架构。事实上，要使其像 request/response 一样工作，需要在 webSocket 协议之上构建一个层，以便您可以判断哪个响应与哪个请求对应。 http 本身是 request/response.
- 因为 webSocket 被设计为持续连接（或至少连接一段时间），所以它在两个端点之间频繁通信的情况下工作得很好（并且开销较低）。连接已经建立，可以直接发送数据而无需任何连接建立开销。此外，webSocket 每条消息的开销通常比 http 小。
所以，这里有几个典型的原因，您可能会选择一个而不是另一个。
- 如果您需要能够从服务器向客户端发送数据而无需客户端定期轮询新数据，那么 webSocket 设计得非常好，而 http 无法做到这一点。
- 如果您经常发送大量小数据（例如，温度探测器每 10 秒发送一次当前温度），则 webSocket 比每隔新数据。
- 如果您没有上述任何一种情况，那么您可能真的不需要 webSocket，http request/response 模型可能会更简单。
- 如果您确实需要 request/response 将特定响应绑定到特定请求，那么它内置于 http 而不是 webSockets 的内置功能。
您可能还会发现这些其他帖子有用：
Push notification | is websocket mandatory?
How does WebSockets server architecture work?
对您的编辑的回应
But it seems like a websocket must be running separately from the API, I mean it's another program right? Because it's not for HTTP requests
支持您的 API 的同一进程也可以为 webSocket 连接提供服务。因此，当您在 webSocket 上获取传入数据时，您可以直接将其写入数据库，就像 API 访问数据库一样。所以，不，webSocket 服务器不必是一个单独的程序或进程。
So should the API also listen to this websocket to catch new messages and store them?
不，我不这么认为。只有一个进程可以侦听一组传入的 webSocket 连接。