PUT remains one of the most confusing HTTP verbs because it is so frequently misdescribed, even by people who really do know better. The common description is that PUT is for UPDATE and POST is for creating new resources; and this is wrong, wrong, wrong.
UPDATE, in the SQL sense, means we change some fields to some values; e.g.
SET sucker = true
WHERE bought_extended_service_warranty = true
This is not HTTP PUT at all. HTTP has no notion of a diff or a partial update. The only thing you can do in HTTP is send the entire resource again, to completely replace the existing resource. There’s really no equivalent in SQL, but if you must have one, then PUT is like a DELETE, followed by an INSERT, using the same primary key.
Of course, PUT can also be used to create new resources that did not exist before with new primary keys (URLs). This is sort of like an INSERT with a client supplied primary key.
In fact, POST is better suited to serve as an UPDATE clone if you need one. If you’re updating a page, you can POST a diff or comment to it, and the server can respond by applying those changes to that page. This requires a more intelligent server than most of us have bothered to install. This is also not the only thing that POST can do, but it is well within POST’s allowed behavior. If you really want to duplicate SQL UPDATE in HTTP, you do it with POST, not with PUT.
Bottom line: PUT is for creating and replacing pages. It updates only in so far as replacing an entire page is an extreme case of updating it. POST is the real UPDATE if anything is. Of course, the ultimate reality is that the SQL analogy is strained to the breaking point by both PUT and POST. HTTP is not SQL, and those who persist in thinking of it like that will continue to be confused.