[rusk]

> RPC over REST is a solved problem

I'm interested in understanding more about this statement.

Do you mean that all REST RPC libraries are sufficiently developed such that you don't really need to worry about RPC being tricky, or that we all just as a community understand the best strategies and common pitfalls. Or do you mean a specific technology?

Just wondering cause whenever I hear the term RPC as an experience developer I just shudder (-: Thanks!

[jively]

I meant that there are well discussed strategies for handling calls that are RPC-oriented rather than CRUD, not that there are REST libraries that have solved the problem.

Ultimately we find ourselves building 80-90% CRUD operations with edge cases that don’t entirely fit with the straightforward RESTful toolset, and in those situations making a call on how to handle it in code is a topic that has by now been more or less discussed to death and becomes a stylistic choice.

REST isn’t a protocol, there is definitely interpretation at work.

I was using the term “RPC” to cover topics that are outside the scope of CRUD, “do a thing” as opposed to “manipulate a thing”.

[rusk]

Thanks!

My own personal take on RPC being solved is that we're all pretty much agreed it's not a good idea unless you absolutely have to!

(I mean RPC in it's more narrow definition as remote, synchronous function calls - e.g. CORBA, SOAP, XML-RPC or the original Unix RPC protocol - for me this is what makes the resource oriented approach of REST a much more appealing approach)

[pdpi]

> My own personal take on RPC being solved is that we're all pretty much agreed it's not a good idea unless you absolutely have to!

I'm very much of the opposite opinion — Ideally services are indistinguishable from any other library, and the fact that they're running remotely instead of locally only means there's a couple more (networking-related) error cases to handle. RPC setups like Thrift or gRPC support this way of thinking relatively well, whereas REST's resource/verb paradigm really forces your APIs to have a certain shape.

[rusk]

> Ideally services are indistinguishable from any other library

I don't mean to be dismissive [0] - but that mindset seems a bit prehistoric to me. We tried CORBA, everybody hated it, and it died!

Indeed, the bible on the topic [1] devotes substantial amounts of time to how to structure your interfaces just so that you avoid issues arising from the discrete system boundaries.

There is a world of difference between issuing an instruction that repositions a program pointer from one position in memory to another, and transferring execution from one compute node to another while artificially blocking execution to simulate a single thread of execution.

(Even, on a single machine with multiple cores this can be a problem - though to a much more limited degree)

This is why we prefer loosely coupled, message-passing approaches, and resource-oriented ones such as REST. This is why modern languages have "futures" and "promises" (the implication being that we sometimes break promises) and why functional languages are so much in vogue (specifying "what" and leaving a substrate more sympathetic to the underlying architecture to decide "how").

[0] https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

[1] https://www.pearson.com/us/higher-education/program/Henning-...