Hacker News Reader

Comment by Scaevolus | Hacker News Reader

Distinct RPCs being distinct URLs also makes it possible to easily route and load balance RPCs to different backends, which is lovely for scaling up.

View on HN

JSON RPC tends to embed credentials into the body, where REST puts them in the URL string or headers.

This gives you the advantage of load balancers being able to fast drop misbehaving clients for load shedding. You also have the security advantage of authenticating a legitimate client before handing off the payload to a parser (both as a DoS vector, or the risk of parsing untrusted data).

> JSON RPC tends to embed credentials into the body, where REST puts them in the URL string or headers.

The JSON RPC spec says nothing about authentication, you can use whatever authentication method you wish.

Many people have learned the hard way that it is one thing what the spec says, another what software actually do.

This is a variation of Hyrum's Law: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. https://www.hyrumslaw.com

> JSON RPC tends to embed credentials into the body

Really? For a JSON-RPC over HTTP API? Where?

If you are using a generic JSON-RPC framework (does that exist?) which supports multiple transports then credentials in the request object seems like a good optional feature but surely you could disable it and stick your regular HTTP auth middleware in front?

At that point you're doing OpenAPI, which will dispense with the subject routing boilerplate of JSON rpc, and have a lighter payload that you have to do less work to understand (presumably the JSON schemas are similar to your db tables)

When I’ve considered JSON-RPC in the past, the lack of easily identifiable URLs was the main drawback in my mind due to the difficulty of testing and debugging—the same reason I would never use gRPC or similar on my own projects. That said, I think a well-made browser extension would fix this issue for most people, similar to GraphQL, but it still introduces friction that isn’t immediately beneficial. I’d still give it a try in the future!

gRPC actually does have easily identifiable URLs. Protobufs can be heavyweight, but it's trivial to use a different encoding like JSON.

What do you mean by heavyweight? protobufs should be much faster to work with than JSON.

Not the OP, but: Protobufs are much more complicated on the implementation side than JSON. You at minimum need a protobuf library and a spec for your data that's shared on client and server. Migrations are also a lot more work because you may need to keep around every version of your protobuf in every client and/or server, depending on how synchronized the two are (i.e., if you can guarantee all clients and servers are upgraded 100% synchronously, as on a web site, then it's not so bad, but if clients are apps or peers that may or may not be upgraded, then the server may need to speak many different versions of a protobuf).

These all qualify as "more heavyweight," at least from an implementation perspective.

> because you may need to keep around every version of your protobuf in every client and/or server

That shouldn't be necessary. Protobuf changes are supposed to be additions-only, where existing field numbers never change their meaning, but new optional/default fields are added. If you do that, you only need one version of the proto spec.

I stand corrected!

Reply on news.ycombinator.com