Ask HN: Why isn't JSON-RPC more widely adopted?
I have experience working on some JSON RPC Load Balancer, and I can tell that it&#x27;s one of the worst choices for an API:<p>- Method Name is a part of the body itself. So you have to parse it to make a decision on how to dispatch it. That&#x27;s an extra cost.<p>- Error Code is a part of the response. So you have to parse it each time to figure out if it&#x27;s a success. Also, some clients just give an HTTP Error Code instead. So you have to handle both.<p>- It can also be batched. Which introduces a lot of unspecified use cases.<p>- Like how are you supposed to dispatch those batched? Should they go to the same upstream? Or can it be parallelized? Should the order be preserved?<p>- With batches, the slowest request always blocks the in-flight response. You have to wait for all calls to be finished before producing a final response. That&#x27;s a huge performance bottleneck. Also, what you do if some of them never finished?<p>- A lot of uncertainties about the ID. Especially because it can be a different type (int or string), which sometimes introduces two different handlers in the code. And there are no guarantees IDs are not repeating in the same batch. To make it worse, some clients rely only on the request&#x2F;response order ignoring the IDs.<p>- Another problem is that it has no idea of Metadata, which is important for many real systems. For example, to do an Auth. Or do Caching and other optimizations.<p>So as an outcome, everyone just makes two layers. On the HTTP level, you have auth, routing, error handling, multiplexing, etc. And then you realize that JSON RPC only introduces extra complexity.