Where REST makes that awkward is that many "verbs" I want to use in my API result in multiple such objects being created on a server, and multiple objects being returned (in some wrapper class), and that's awkward with REST because REST is all about making those nouns directly accessible. I don't want that. I want a vocabulary of actions. My client "does things". Doing is a verb. Verbs operate on nouns. The nouns will all exist but they themselves aren't the API.

My other gripe is that I don't want the tech stack dictating to me ahead of time what my verbs are. Some of my verbs might do a create, and update, and some deletes, all in one verb as part of a transaction. There's no such thing as "Is this a create or an update or a delete API call?" It might be all those simultaneously.

Each API call should have a unique Request object and and Response object. When your request/response are specific verbs, you can then later rename the verbs and easily add additional info to the Request and/or the Response without redesigning all your objects. Objects should be designed to model the data itself and NOT have any direct relationship to the API. Objects are in the language of the API verbs, but they don't control it.

For example, SQL has simple verbs because it doesn't want to know what are the actual operations executed by the application (for example, verifying status of an existing process, checking optimisting lock, etc.)

Another example are some remote memory interfaces which basically transfer blocks of memory back and forth without knowing what is the operation for. You build your higher level, business logic-aware protocol on top of it.

The same way, REST is about intentionally not getting involved with the imperative style and instead provide transport protocol that will make it possible to refer to the things as resources, discover resource graph through hyperlinks, etc.

The business logic is supposed to introduce changes to the object but use REST to only transfer representation of the changed state (Representational State Transfer) without burdening it with RPC details.

That is why so many APIs fail to use REST effectively, because designers do not understand the goal and limitations of REST. It is conscious decision not only what the API does but also what it is not supposed to do.

To update the user the REST-ful way would be to allow the client to fetch the user document, introduce changes client side with whatever logic the client wants and then transfer the representation of modified state back to the server with a simple verb (same way we interact with filesystem through reads and writes without kernel ever knowing what this is). The server decides what to do with these changes.

Trying to burden the kernel with information about what the operation is is futile but that's what usually happens when people design "REST"-ful APIs.

I'd politely disagree with that. I think most REST fanatics ACTUALLY DO claim that their beautiful arrangement of nouns and their 4 CRUD verbs are capable of replacing RPC, because they've become convinced the "procedure" part of RPC, means that RPC is inherently built around functional programming which is verbs, and they think they've found a better way than using a custom vocabulary of verbs.

So they're using REST instead of RPC, because "verbs are bad".

I'll just restate my opinion that the concepts of "functional programming" are not somehow rendered obsolete whenever the machine you're talking to happens to be remote. Sure, there are certain challenges involved with designing a 'remote' API that can arise involving latency and bandwidth considerations, but those limitations in no way imply a solution where you throw out your entire set of "verbs", like REST does.

Of course, you then build up functionality over those base verbs, just like in a program. But your programming language doesn't have a verb for each function you might want to write. It just has the base 'call' verb.