CRUD applies to database-level operations. REST applies in the context of services and APIs. REST operates on resources -- the concrete implementations of conceptual business entities, the "nouns" (persons, places, and things) that our information systems are intended to manage.

The structures that persist this crucial data and the operations that manage it must be granular enough not only to support the explicit and immediate needs to the current application state but the needs of modern organizations to experiment with A/B/n tests.

Get rid of CRUD entirely, and you cripple the enterprise, often for life.

Tasks are steps in a process. Coding and maintaining a task for each resource property isn't SOLID as SOLID was intended. It results in a huge increase not only in code but in the complexity of your API. It shifts the work required to understand and utilize it correctly to developers rather than abstracting its complexity to make it easy to use.

Processes, not tasks, should orchestrate these lower-level resources or entity data. Processes are the "verbs" in our systems, and calling them can certainly be accomplished in a REST style but is more like a Remote Procedure Call (RPC).

It's important not to conflate these two very different but very important and necessary types of operation invocation and their intents.

Personally, I try to make it clear from the outset in the URL:

[baseUrl]/entities/1_0/users for CRUD operations

[baseUrl]/processes/1_0/registerUser for process invocations

The process layer (or better yet, the data layer) contains the upsert logic to determine whether a resource exists and which fields should be updated or should to be created.

Remember, machines are supposed to be working for us, not the other way around.