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.
I think with functional programming developers are capable of knowing whether they're creating or updating a user.
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.
You're right. No one knows what rules apply to transmogrification. That's why people use the http verbs to consistently create and edit things without having to look up the caching and idempotency rules of every random thing your API does.
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.
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.