It's not that they are preferable, it's just that these verbs were invented for a reason, and people often ignore that because they didn't RTFM. POST can be th

It's not that they are preferable, it's just that these verbs were invented for a reason, and people often ignore that because they didn't RTFM. POST can be thought of as pasting a file into a folder from your clipboard, without necessarily knowing what its filename is. It oughta tell you the filename after you paste so you can retrieve it later. Typically, in a REST setting, you'd POST a thing to a collection (e.g. POST /api/v1/things) PUT can be thought of as piping stuff to a file, when you know the filename ahead of time. It completely overwrites any existing data in that file. You'd PUT to the path where the resource should exist (e.g. PUT /api/v1/things/1) PATCH can be thought of a version control diff. It's actually really powerful, but unfortunately, there's no widespread format to express diffs of deep structural data often seen in REST APIs, so most people avoid it. A PATCH request should contain instructions on how to add and remove sub-fields from a resource. It can be used on collections to batch-add/remove items, and it can be used in single resources to modify them without overwriting other existing fields (or even do all of those with a single request)