REST vs RPC
The cluster centers on debates comparing RESTful APIs to RPC mechanisms like gRPC, JSON-RPC, and SOAP, questioning if modern REST is just RPC over HTTP and discussing their architectural trade-offs.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Sounds like the API's you're talking about are some flavour of RPC.So rephrase your own question: what's wrong with RPC?
Isn't REST is a way to implement RPC?)
Why? What's so limiting about calling remote services over HTTP?
What is commonly referred to as “REST” isn’t actually REST, and trying to cram that round peg into that square hole is a hobgoblin of little minds IMO. In practice, “REST” can be simplified to RPC over HTTP using JSON as a wire format. Or you can use gRPC and get strong typing and explicit RPC semantics instead.
If HTTP is a bad fit for RPC interfaces, is there something that is a better fit?
RPC is a low level API for which you have to set up and implement many parts that HTTP delivers out of the box. RPC probably not even has a significant performance advantage.
RPC usually means stateful client so REST goes out the window.
To reiterate what someone else already said: no, REST was never meant to be “just RPC”. If you want RPC over HTTP, use something like JSON-RPC rather than trying to invent it yourself; its creators have already solved many of the problems that you’re about to hit.The term REST (short for Representational State Transfer) was defined by Roy Fielding in a dissertation in 2000. There are many ways in which REST is better suited for web APIs than the RPC model: some of them are about communication
I’m disappointed to see this comment. What don’t you think can be expressed with REST that can be with RPC?
REST is the solution to this but it's reduced to JSON RPC over HTTP nowadays.