CODEWITHSUNDEEP
restrpc
user3134477
user3134477

Reputation:

REST vs RPC - *Actual purpose* differences

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:

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...

Upvotes: 5

Views: 9685

Answers (1)

Evert
Evert

Reputation: 99533

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.

Upvotes: 6

Related Questions