I feel like in the last 10 years there's been a (mostly unconscious) swing from "document" or "resource" oriented modeling in APIs back to RPC type "command" APIs; due in large part to the new popularity and ubiquity of distributed RPC systems like gRPC (or Thrift, etc.)
The "REST" trend crested, and RPC came back with a vengeance. Or people just abused RESTful appearances but pasted command and remote-call semantics in overtop of it.
I still think that extensive use of RPC on the Internet has the problem of (deliberately) giving the application developer the illusion that the world of the remote and the local are in the same "system", thereby hiding the intrinsic problems of reliability and latency with communicating over a socket. I feel like this is maybe why a lot of systems that should "know better" fall down when they lose good network connectivity (looking right at you, Android Auto): the developer has not been forced to think about failure conditions because the framework fooled them into thinking that accessing the remote resource was semantically the same as accessing a local resource.
I'm not convinced. Should we use command messages like rpc calls? No. But the category of command message makes sense. A command might fail. Only events are saved to the log. I think the separation of commands into ephemeral requests that may or may not result in new events on the log is a very reasonable distinction.
some old copy