According to RFC 9110: - POST: Perform resource-specific processing on the request content. - PUT: Replace all current representations of the target resource

According to RFC 9110: - POST: Perform resource-specific processing on the request content. - PUT: Replace all current representations of the target resource with the request content. I interpret this as the only immediate side-effect of PUT is supposed to be replacing the target resource with the request content. Everything else is POST, but that does not mean that we can't use POST for everything. Thus, JSON via PUT is not inherently odd at all. Calling a random API using PUT with JSON arguments that executes some code other than replacing a resource, would be odd. I do think, though, that PUT may very well implicitly create a resource, if the name of that resource is the argument to the put. That is just something that's rather odd, as, often, the server has authority over the names of new resources. I find PUT particularly helpful, as, given these constraints, I assume that PUT is idempotent; POST is not.