It isn't just a convention, the reasons for doing this are laid out in the HTTP 1.1 spec and assumed by servers, proxies, browsers, clients and developers.
For example if I hand someone an API with a URI that accepts a PUT they know they can safely retry PUTs to that endpoint because the server state will always end up the same.
there is nothing in the specification of the PUT verb that indicates it is meant only for complete replacement of an existing resource. in fact, the RFC specifically has a section describing the semantics of creation using PUT. therefore, either your stance is trivially falsified, or you were replying to me out of context, which is intellectually dishonest.
> The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.
It is pretty clear to me that the spec says PUT completely replaces the state of a resource. So not just a convention but what the spec says.
BUT lets take it further. Lets say you do allow partial updates with a PUT. Can you guarantee that your resource's state will always be internally consistent?
Say you have two clients, both doing partial PUTs and do the following:
Client 1: GET /foo
Client 2: GET /foo
Client 1: PUT /foo {'bar': 1}
Client 2: PUT /foo {'baz': 2}
Is the foo resource is a consistent state? For some applications it could be but for many it won't be. And worse for some applications it may not be idempotent and a client's proxy is going to silently retry a PUT that isn't safe to do so.
So by allowing partial PUTs we're requiring the developer to consider all combinations a resource could be updated. They then need to communicate the valid combinations to any clients.
OR they can split the resource up finer grained resources, each one representing a valid PUT.
so since the post I replied to said that POST is for create, and PUT is for complete replacement, and you just indicated that PUT can be used in ways that the OP did not, and I objected to the OP's prescriptivism, you agree with me despite your stance of arguing with me about it.
For example if I hand someone an API with a URI that accepts a PUT they know they can safely retry PUTs to that endpoint because the server state will always end up the same.