Your API could be mapped to a filesystem. (Although you might consider consider a filesystem a database.) If this were the case, it would make sense to use PUT for commands like chown and chmod, which are idempotent. Calling "PUT" "CREATE" here would (IMO) be confusing. I'm not creating something. I'm performing an action, putting things in their proper place, if you will. Another example could be home automation. You might design a REST API where you can PUT cameras to turn them on.
The way I see it, the great thing about HTTP verbs is that they are mostly (not all) unbiased about what they map to, and allow us to be more descriptive. If I'm inspecting the requests my browser is making, I'd much rather see "DELETE /path/to/resource" than see "POST /path/to/resource" and only discover that that call deleted my resource because the body of the request contained '{ "action" : "delete" }'.
Doing a "chown" or "chmod" would be an UPDATE operation, not CREATE. The permissions and owner values already exist by value of the record existing, so of course trying to call CREATE on them seems silly. Same with turning cameras on/off; that's UPDATE on the state on the camera. CREATE would be to add a new camera to the system.
> Doing a "chown" or "chmod" would be an UPDATE operation, not CREATE.
Right, which is why calling PUT to do them "CREATE" would be confusing. But PUT is still the right verb (well, for things like chmod 777; for chmod +X, PATCH would be better.)
The way I see it, the great thing about HTTP verbs is that they are mostly (not all) unbiased about what they map to, and allow us to be more descriptive. If I'm inspecting the requests my browser is making, I'd much rather see "DELETE /path/to/resource" than see "POST /path/to/resource" and only discover that that call deleted my resource because the body of the request contained '{ "action" : "delete" }'.