The intended effect (semantics) of the POST method is resource specific, e.g. executing a command with arguments:
POST /command HTTP/1.1
{"parameter-1": "argument-1", "parameter-2": "argument-2"}
The intended effect (semantics) of the PUT method is to create or replace the state of the target resource with the state defined by the enclosed representation, but the side effect of the PUT method is resource specific, e.g. executing a command with arguments:
PUT /command HTTP/1.1
{"parameter-1": "argument-1", "parameter-2": "argument-2"}
Cf. RFC 7231, § 4.3.4:
A PUT request applied to the target resource can have side effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version (different resources that at one point shared the same state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added between the related resources.
So what are the benefits of executing a command as the intended effect of POST versus as the side effect of PUT?
/command
resource has no purpose (the user is not interested in retrieving it with GET), use POST instead of PUT?A PUT request applied to the target resource
. It's not like you are pointing or handling any resource, you are merely executing remote procedures. Don't know if method semantics applies here. I would dare to say that it doesn't matter whether you use POST or PUT. I'm somewhat sure that you are not returning the header "Resource-Location" + 204 Status after POSTing a command. So why you care about semantics?