К чему тогда эти вопросы? Именно там это плотно используется. Даже если вы делаете это на JS, как выше написали, считайте, что у вас в рамках сайта работает API.

Пых без хирургических инструментов плохо поддерживает доп. методы, например не разбирает PUT-параметры. Нужно страдать фигней вроде той, что выше показали, а ведь параметры в добавок могут быть переданы не в URL-формате!

Идемпотентность – это когда одинаковые запросы приводят к примерно одному и тому же результату. Например, когда ты PUT-ом пишешь одни и те же данные, ты обновляешь один и тот же объект, а когда POST-ом, то типа каждый раз создаешь новый (дополнительный), т.е. копию предыдущего, но с др. идентификатором. Это все каноны. Конечно, можно и по-другому. Например, у нас много адаптированных API исключительно под GET/POST. Только совсем уж не перегибайте палку. Например, я ржу-не-могу, когда вижу, как пытаются удалять GET-ом (по ссылке).
(Добавление)
Да. Но там многое завязано на адресацию. Типа GET/POST не достаточно для полного CRUD'а с типичной REST/HTTP-адресацией. Например:
GET /objects – получить данные/список объектов коллекции;
PUT /objects – обновить (собственные) данные коллекции;
DELETE /objects – удалить коллекцию;
а теперь вопрос: Как создать новый объект данной коллекции? Правильно,
POST /objects

В принципе глаголы PUT/POST можно было легко поменять местами, но для определенности решили их использовать так.

miketomlin для обновления PATCH
PUT для создания с заранее известным link(id передаем вместе с данными)
POST - создание и возвращение link(id генерит сервер)

LIME, для обновления тоже обычно используется PUT. PATCH – это для более сложных способов обновления: https://tools[dot]ietf[dot]org/html/rfc5789 (первый абзац). Когда ты реально выполняешь частичное обновление, желая сократить трафик и т.п.