Modeling Server Streaming JSON RPCs

Skip to first unread message

Jonathan Whitaker

Sep 25, 2020, 1:16:00 PM9/25/20
I would like to use the JSON-RPC specification to build a JSON RPC API over Websockets. My use case is for a JSON RPC Pubsub API. Clients should be able to publish messages (single or batch request/response) and subscribe to messages(single subscription request but the server streams back responses). How would you recommend modeling that with JSON-RPC?

Would it be best to just respond back from the server with a successful response indicating receipt of the request, and then also continue to respond back (out of band) with the messages coming off of the subscription?

I'm interested to hear what other people have done.

Alexandre Morgaut

Sep 25, 2020, 4:41:15 PM9/25/20
to JSON-RPC group
I invite you to give a look at the Chrome DevTools protocol

It is a JSON-RPC protocol working on Websockets allowing to perform remote debugging processes based on the V8 JavaScript engine (and for Node.js and all Blink based Browsers)

You can find a lot of libraries (client & server libraries) in many languages (JavaScript, TypeScript, PHP, Python, Ruby, Go, Rust, Java, Kotlin, Closure, C#, Objective C)  built over that protocol:

It does have the notion of subscription over dedicated api-level methods like

  - Network.enable: Enables network tracking, network events will be delivered to the client.
  - Network.disable: Disables network tracking, prevents network events from being sent to the client.

- It is more using a JSON-RPC v1 without batch but you're free to use the v2 for your own protocol  

You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Andrew Arnott

Sep 26, 2020, 9:59:05 AM9/26/20
StreamJsonRpc is a JSON-RPC 2 implementation that works over a duplex stream (including web sockets). It supports the client and server exchanging a "out of band Stream" so that during or after the RPC request the client and server may continue to communicate (one way or two way) in a streaming fashion. This is great for streaming, or sending binary data so that it needn't be JSON encoded.

The multiplexing stream protocol it uses is implemented in .NET and Javascript so far. I'm not sure if that makes it applicable for you. Given the multiplexing stream, doing the out of band streaming on top of JSON-RPC becomes very simple.

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

Reply all
Reply to author
0 new messages