我正在制作一个流式 API，它处理 RPC 样式调用以及从服务器到客户端的通知(不是 JSON-RPC 规范中的客户端到服务器的通知)。不幸的是，最后一部分排除了 JSON-RPC + 持久 HTTP。

API 基于 JSON 和 JSON-RPC 规范。

JSON - http://www.ietf.org/rfc/rfc4627.txt

JSON-RPC - http://www.jsonrpc.org/specification

典型的 session 可能是:

-> Sending to server
<- Receiving from server    

-> {'id': 0, 'method':'login','params':{'token':'secret'}}
<- {'id': 0, 'method':'login','result':0}
-> {'id': 1, 'method':'subscribe','params':{'symbol':'VOD.L'}}
<- {'id': 1, 'method':'subscribe','result':0}
...
<- {'method':'notifyPrice','params':{'symbol':'VOD.L', 'bid':10.1, 'ask':10.03}}
<- {'method':'notifyPrice','params':{'symbol':'VOD.L', 'bid':10.2, 'ask':10.03}}

上述消息，尤其是通知，可以以任何顺序出现在同一个数据包中。这两个规范似乎都没有包含消息分隔符的详细信息，这使得在不使用基于 SAX 的 JSON 解析器的情况下很难知道何时收到了整个 JSON 消息，这与对应的 DOM 解析器相比相当罕见。

我是否遗漏了一些明显的东西，或者是否真的没有标准的方法来区分通过网络传入的多个 JSON 消息？

最佳答案

你错过了什么:-)

每个 JSON-RPC 消息都是一个有效的 JSON 值。 JSON 值可以是以下任何一种:

• 一个数组
• 一个对象
• 一个字符串
• 一个号码

JSON-RPC 信封是一个对象。

如果这是一个原始套接字(如 Telnet)，那么......

对象以{开始，以}结束。 如果您在接收器上使用正确类型的解析器(拉式或面向事件的)，那么 Object 和 Array 的嵌套方式并不重要，您仍然会知道何时点击最后一个 }。

The above messages, particularly the notifications, could come in any order and in the same packet.

只要请求没有交错(一个在下一个开始之前完成)，就完全没有问题。这取决于您是否还需要信封的换行符终止(也称为面向行的协议(protocol))。

但是，当您处理 HTTP 时...

为什么不直接使用 batch符合 JSON-RPC 规范的消息？

https://stackoverflow.com/questions/24471689/