REST vs RPC - Actual purpose differences

Question

I started writing web-apps and distributed apps when REST was already popular, so I actually never used RPC.

When searching for a simple explanation of the difference between them, I started to understand, but some examples got me confused.
I saw things like this:

GET /getLastUser

or this:

POST /changeUserName

If REST is meant for resources, and RPC is meant for procedures, isn't it a bad practice using RPC for something like this?

Correct me if I'm wrong, but the way I see it, RPC should be more purely functional.
Meaning that calling a procedure should always:

return the same result for the same arguments
not affect state

So, RPC calls like this:

GET /addTwo?num=5

that return something like this:

{
    "result": 7
}

seem more logical to me (although that's a very simple example).

If this question gets closed for being too "opinion-based", I'll just know that I should do whatever the heck I want...

This explains it fairly well https://stackoverflow.com/questions/26830431/web-service-differences-between-rest-and-rpc — twoleggedhorse, Sep 10 '17 at 20:57
As does this https://sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc — twoleggedhorse, Sep 10 '17 at 20:58

score 6 · Accepted Answer · edited May 11 '20 at 07:51

RPC is not meant to be functional. Calling a same procedure twice gives no guarantee about the result.

This question can be answered a few different ways, and pretty deep. I think this might be a fair summary.

With RPC the primitives typically are function names, arguments and results.
With REST the primitive is a 'resource representation'.

So where with RPC you might call a function, in REST you are really sending and retrieving the state of a resource, regardless of protocol.

This means you typically only ask a server 'can you give me the state of this resource', or you tell a server 'here's a new resource state, please store it at this location'. The only successful answers REST will give are "the current state" or "this operation worked", but with RPC the question (function + arguments) and answer (the result) can be anything.

So you can argue that when you describe it like this, RPC is a lot more flexible. It probably is, but because REST confines itself to just transmitting state, you gain a lot of guarantees that a simple RPC-based protocol does not give.

REST is not just about transferring state. The usage hyper-links is another important requirement for a service to be called REST, and this is also something that you don't get 'out of the box' with RPC.

Lastly, it can be argued that HTTP itself is an RPC-like protocol. I think it's possible to build a RESTful service on top of any RPC service.

@user3134477, not necessarily but this is true under very specific conditions. When most read REST, they think of a typical implementation of REST on HTTP. For most practical purposes they are two completely different things, but when you go down to the theory REST can be done on top of a RPC protocol. — Evert, Sep 11 '17 at 14:20

REST vs RPC - *Actual purpose* differences

1 Answers1

REST vs RPC - Actual purpose differences