However with REST I can't "transmogrify" a user. Do you know what a "transmogrification" is? No you don't. Because REST doesn't do that. It's a domain specific verb I made up.
To force REST to work you'd have to invent a new noun called "transmogrify state", even if no one would have ever conceived of that state in a functional programming design. Whenever you end up inventing new objects specifically to work around architectural limitations, that's not a simplification. :)
Functional Programming works. Nothing invalidates verbs just because you're doing them over HTTP, for example. Your API design should have no clue if it's running over HTTP or something else.
If your API had a /transmogrification/<id> resource. I would know how to query its state and possibly edit it. I have a clear place to look for previous transmogrifications without crating a new one and I even have a nice query syntax support.
Or maybe you don't support GET and return a 405 response. That's ok too.
* Limits number of verbs to CRUD ones (HTTP).
* Makes every verb into a noun.
* Tightly couples HTTP-codes into your API.
* Requires creation of many endpoints you don't really need.
* Makes it awkward to have a single request that updates multiple different types of objects, or queries different types of data.
yeah, I don't want any of the above in my life.
Well for anyone else listening, a RESTful design would help you know whether you're creating or updating a user. You would know if you're allowed to repeat the request without side effects. That's useful in a distributed api where half open requests are inevitable.