4 ms·

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 assum

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.

pixie_ 9y ago
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.
- speedplane 9y ago
  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").
  - sidlls 9y ago
    Why does that matter? Most of the time the client doesn't care about the implementation details of the data transfer.
- nickjj 9y ago
  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.
OtterCoder 9y ago
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?
- DougBTX 9y ago
  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.

pixie_ 9y ago

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.

speedplane 9y ago
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").
- sidlls 9y ago
  Why does that matter? Most of the time the client doesn't care about the implementation details of the data transfer.
nickjj 9y ago
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.

OtterCoder 9y ago

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?

DougBTX 9y ago
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.