REST is centered on resources (nouns), RPC is centered on procedures (verbs). REST is more constrained.
A Remote Procedure is just that, a procedure. Procedures don't have many constraints. They can implicitly change the state of resources on the server. They can do whatever you want.
REST APIs are supposed to be designed around state transfer. You transfer the state of a resource from server to client with a GET. You transfer the state back to the server with a POST/PUT. The operations are supposed to be 'stateless' in that the result is not supposed to depend on the pre-existing state of the resource on the server.
To give a silly example, let's say I have a Counter service. In RPC I could expose a incrementByOne procedure. And then clients could just call:
incrementByOne(id=1)
In REST I would have a Counter resource. The RESTful way to increment the counter would be:
GET /api/counter/1
-> OK {'id': 1, 'value': 12}
PUT /api/counter/1 {'id': 1, 'value': 13}
-> OK
It's more cumbersome, but notice that unlike the RPC call, the result of the PUT request doesn't depend on the current state in the server. The counter will always end up at 13. The PUT request is idempotent, I can repeat it n times and end up with the same result. Obviously that's not true with the RPC call. Notice also that the client must implement its own logic for incrementing.
You could design a RESTful RPC, where the only methods are like:
getCounter(id) -> Counter
createCounter(Counter) -> id
putCounter(Counter)
The opposite, RPC over REST, doesn't really work. I guess you could try representing procedures as resources but it would be incredibly awkward. That's why I say REST is more constrained.
With well designed REST you should end up with very decoupled logic between server and client since all they can do is transfer state, they each have they wholly separate logic to deal with the state.
With RPC you can end up with some real spaghetti, where the logic of client and server are intertwined. But not everything can be modeled cleanly as resources, sometimes you really do just want to execute some logic on the server.
A Remote Procedure is just that, a procedure. Procedures don't have many constraints. They can implicitly change the state of resources on the server. They can do whatever you want.
REST APIs are supposed to be designed around state transfer. You transfer the state of a resource from server to client with a GET. You transfer the state back to the server with a POST/PUT. The operations are supposed to be 'stateless' in that the result is not supposed to depend on the pre-existing state of the resource on the server.
To give a silly example, let's say I have a Counter service. In RPC I could expose a incrementByOne procedure. And then clients could just call:
In REST I would have a Counter resource. The RESTful way to increment the counter would be: It's more cumbersome, but notice that unlike the RPC call, the result of the PUT request doesn't depend on the current state in the server. The counter will always end up at 13. The PUT request is idempotent, I can repeat it n times and end up with the same result. Obviously that's not true with the RPC call. Notice also that the client must implement its own logic for incrementing.You could design a RESTful RPC, where the only methods are like:
The opposite, RPC over REST, doesn't really work. I guess you could try representing procedures as resources but it would be incredibly awkward. That's why I say REST is more constrained.With well designed REST you should end up with very decoupled logic between server and client since all they can do is transfer state, they each have they wholly separate logic to deal with the state.
With RPC you can end up with some real spaghetti, where the logic of client and server are intertwined. But not everything can be modeled cleanly as resources, sometimes you really do just want to execute some logic on the server.