REST vs RPC

There's a history of arguments about REST.

REST (Representational State Transfer) is a specific way to share data (using the specs for HTTP and URI), designed around client-server architectures.

This is a modified version of a concept that Martin Fowler refers to as the "Richardson Maturity Model (RMM)".

It's a way to evaluate RESTfulness.

Roy Fielding, who was involved in developing HTTP and URI (legend), introduced REST in his famous dissertation.

REST was designed to supersede RPC (not SOAP!).

RPC (Remote Procedure Call) is another way to share data, where an app calls a function in another app, as if they shared the same execution environment.

Leonard Richardson's model (RMM) describes the relationship between REST and RPC.

Each stage of maturity towards REST relies more on HTTP and URI specs than the previous.

Funnily enough, the original Web3 concept was about full discoverability: the Semantic Web.

However, most RESTful APIs today are at the second-highest level, with developers using multiple URIs and HTTP methods to design their APIs.

Only a minority of APIs include resource links from the root /, which allows the shape of the API to be machine-readable.

As a pragmatist, I think the OpenAPI specification mostly takes care of human readability. Adding links (e.g. using JSON-LD) is a relatively easy win to improve machine readability.

On the other hand, organising around common hypermedia is possibly the most challenging constraint of REST.

An aside

The new Web3 relies on RPCs between nodes, better fitting a distributed computer like Ethereum since the network acts like a single application.

P2P connections using RPCs steps back from REST, which largely enabled the architecture of the modern Web.