Hacker News Reader

Comment by speedplane | Hacker News Reader

If you're defining an RPC protocol in just a few minutes, you're leaving a ton of stuff out. Anyone that assumes an RPC call will successfully complete or assumes the network is always there, is writing buggy code. An "RPC protocol" makes writing such buggy code easier. A REST protocol makes it slightly harder. In theory, they are almost identical. But in practice, developers equate RPC calls with function calls, which they are definitely not.

View on HN

Too bad the first thing people do when consuming a REST API is to put a RPC wrapper around it (or find software that with auto-gen a wrapper for them)

Subconsciously no one wants to deal with your carefully constructed REST URLs. They just want a function name and some parameters.

There's nothing wrong with wrapping REST APIs, as long as you wrap them in something that makes it clear they are a rest API. There's a huge difference in call foo() and calling http.get("foo").

Why does that matter? Most of the time the client doesn't care about the implementation details of the data transfer.

Yep, this is pretty much how it always goes.

A good example to me is Stripe.

I've written over 10 applications that use Stripe and every single time, the first thing I did was use Stripe's official library for the languages I work out.

How is it any different in any way than any other async function? You just end up providing an unusually large number of parameters via headers and body, then at some point in the future the request completes with values and/or errors. What separates them?

Classic RPC functions would never be async, since the idea behind RPC is to replace a sync local function with a sync remote function, without having to make any changes to the calling code.

"Async RPC" is a more recent idea, but still gets referred to as "RPC", so the complaints about classic RPC still get raised since the term is overloaded.

Reply on news.ycombinator.com