> I've shown you a small library which allows me not to parse anything at all. I looked at your repo. It doesn't implement JSON-RPC or parse JSON-RPC requests

> I've shown you a small library which allows me not to parse anything at all. I looked at your repo. It doesn't implement JSON-RPC or parse JSON-RPC requests, so I guess you are talking about alternatives to JSON-RPC. An RPC protocol using your library's SICK format may well be efficient (though I'm not sure it's efficient to serialise). When I saw your initial reply I thought your were saying the criticism of JSON-RPC was incorrect in the comment you were replying to. But now I realise you were saying a different protocol not using JSON can be more efficient than JSON-RPC, using a differently request format which could be used as a drop-in replacement for JSON in JSON-RPC. > If I use JSON-like data structures I don't have to use classic parsers with intermediate AST representations. Indeed, but JSON-like data structures are potentially in the "too much overhead" category by themselves, regardless of whether a classic parser is used. Parsing per se isn't necessarily the main overhead: JSON itself can be streamed as tokens. Even with your SICK format, the data structure has to be converted to target language structs, enums, etc, which is a type of parsing, even though it's not parsing text. > The whole idea of RPC is about "knowing the shape" (typing) and good RPC implementations do that. Indeed. The type of a JSON-RPC request is known only when the "method" key is read, and that key can occur anywhere in the top-level object. Start, middle or end. Finding "method" requires at minimum a pattern-matching scan of the JSON body. Until that's done there's no way to know what types the other values in the JSON body are to be mapped to in the API's target language. So we can agree good RPC implementations "know the shape" when reading a request body, and JSON-RPC doesn't have that property. (A variant of JSON-RPC which uses an array with the method in the first element does have that property though. That one has the merit of the high level of cross-language tool compatibility due to JSON, a 1:1 correspondence with JSON-RPC requests, plus the capability to serialise/parse directly from/to target API structs, variables, enums etc in whatever language without requiring any intermediate JSON-like data structure.)