There is no "vs" in RPC and REST in the same way there is no "vs" in fruits and apples. A set of all possible APIs within the RPC paradigm completely contains the set of all possible APIs within the REST paradigm. Draw a circle of RPC and the circle of REST is inside of it, fully enclosed and not sticking out. No RESTful API exists, that wouldn't also fall under the RPC philosophy. You can create an API with an originally RPC-esque framework that will follow every constraint of REST. Take gRPC, just name you procedures GetAbc(id), UpdateAbc(id), DeleteAbc(id) and make sure there is no state. Done! You got yourself something that's both an RPC API and a RESTful API. RPC is any verbs, REST is four verbs. The set of any contains the set of four.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There is no "vs" in RPC and REST in the same way there is no "vs" in fruits and apples. A set of all possible APIs within the RPC paradigm completely contains the set of all possible APIs within the REST paradigm. Draw a circle of RPC and the circle of REST is inside of it, fully enclosed and not sticking out. No RESTful API exists, that wouldn't also fall under the RPC philosophy. You can create an API with an originally RPC-esque framework that will follow every constraint of REST. Take gRPC, just name you procedures GetAbc(id), UpdateAbc(id), DeleteAbc(id) and make sure there is no state. Done! You got yourself something that's both an RPC API and a RESTful API. RPC is any verbs, REST is four verbs. The set of any contains the set of four.