I'm on team RPC. I'll stay away from the term REST since my beef is with HTTP APIs that mix transport and application concerns. - The Kingdom of Nouns comparis

I'm on team RPC. I'll stay away from the term REST since my beef is with HTTP APIs that mix transport and application concerns. - The Kingdom of Nouns comparison is forced. Yegge's complaint is that nouns own the verbs, meaning Java doesn't have first-class functions. The closest remote analog might be promise-pipelining which doesn't have much headway other than a single implementation for Cap-n-proto. - RPC APIs are more consistent than an HTTP API. With HTTP, a unique method requires both a path and method, and if you're really unlucky, the method is polymorphic based on the contents of the request body. - HTTP API requests can transport in different ways: request body, query parameters, HTTP path, and if you're really unlucky, headers. Tremendous gains doesn't match my experience. The first step in using a HTTP API is to wrap it with an OpenAPI generator to build a consistent way to invoke the API, reinventing RPC client stubs in the process.