Signal-CLI-REST-API 使用中 HTTP 200 响应问题的分析与解决

在使用 Signal-CLI-REST-API 进行消息接收时，开发者可能会遇到一个常见问题：当尝试连接 /v1/receive 端点时，系统返回 HTTP 200 状态码而非预期的 HTTP 101。这个问题通常与 API 的运行模式配置有关。

问题现象

开发者报告在迁移服务器环境后，原有的消息接收功能失效。通过 Postman 和原有脚本测试，/v1/receive 端点始终返回 HTTP 200 响应，而不是建立 WebSocket 连接所需的 HTTP 101 状态码。这导致实时消息监控功能无法正常工作。

根本原因

经过排查发现，这个问题源于 Signal-CLI-REST-API 的运行模式配置。该 API 支持两种主要运行模式：

1. 普通模式(Normal Mode)：在此模式下，/v1/receive 端点会返回历史消息记录，采用常规 HTTP 请求/响应机制，因此返回 HTTP 200 状态码。

2. JSON-RPC 模式：只有在此模式下，/v1/receive 端点才会提供 WebSocket 功能，返回 HTTP 101 状态码，允许建立持续的连接来接收实时消息。

解决方案

要恢复实时消息接收功能，需要确保 Signal-CLI-REST-API 运行在 JSON-RPC 模式下。具体配置方法取决于部署方式：

对于 Docker 容器部署，可以通过设置相应的环境变量或启动参数来启用 JSON-RPC 模式。例如：

docker run -p 8080:8080 \
  -e MODE=json-rpc \
  signal-cli-rest-api

技术建议

1. 模式选择：根据应用场景选择合适的运行模式。如果需要实时消息推送，必须使用 JSON-RPC 模式。

2. 迁移注意事项：在迁移环境时，应检查所有配置参数是否完整转移，特别是运行模式这类关键配置。

3. 测试验证：部署后，可以通过浏览器直接访问 /v1/receive 端点来验证模式是否正确。在 JSON-RPC 模式下，浏览器会显示 WebSocket 连接建立提示。

4. 错误排查：遇到类似问题时，首先检查运行模式配置，这是导致功能差异的最常见原因。

总结

Signal-CLI-REST-API 的不同运行模式提供了不同的功能特性。理解这些模式的区别对于正确配置和使用 API 至关重要。当遇到消息接收功能异常时，运行模式应该是首要检查的配置项。通过正确配置 JSON-RPC 模式，开发者可以恢复实时消息推送功能，构建更高效的 Signal 消息处理应用。