Почему не используются остальные HTTP-глаголы?
В большинстве случаев сайты в основном используют только GET а также POST для всех операций, но есть еще семь глаголов. Где их использовали в старые времена, но не так много сейчас?
Или, может быть, это потому, что некоторые браузеры не распознают другие глаголы? И если это так, то почему производители браузеров предпочитают реализовывать половину протокола?
[Обновить]
Я нашел эту статью, которая дает хорошее резюме о ситуации: почему REST не удалось.
3 ответа
Спецификация HTML - большой преступник, только на самом деле разрешающий GET, POST и HEAD. Хотя они немного привыкли, но не так сильно прямо в браузерах.
Чаще всего используются другие грубые глаголы, такие как PUT и DELETE, в сервисах REST и WebDAV.
В будущем вы увидите больше ОПЦИЙ, поскольку они используются в спецификации CORS (междоменный домен xmlhttprequest).
TRACE практически везде отключен, поскольку представляет довольно большую угрозу безопасности. CONNECT определенно используется прокси-серверами довольно часто.
PATCH совершенно новый. Хотя мне странно, что они решили добавить его в список (но не в PROPFIND, MKCOL, ACL, LOCK и т. Д.), Я думаю, что в будущем мы увидим, что он появится в сервисах RESTful.
Приложение: оригинальный браузер использовал и GET, и PUT (последний для обновления веб-страниц). Более поздние браузеры в значительной степени стали доступны только для чтения, пока формы и POST-запросы не попали в спецификации.
Большинство из них все еще используются, хотя и не так широко, как GET или POST. Например, веб-сервисы RESTful используют PUT & DELETE, а также GET & POST:
Веб-сервис RESTful - статья в вики
HEAD очень полезен для отладки HTTP-заголовков на сервере, но так как он не возвращает тело ответа, он не слишком полезен для браузера / обычного веб-посетителя...
Другие глаголы, такие как TRACE, не так широко распространены из-за потенциальных проблем безопасности и т. Д. Кратко упомянуто в статье Wiki:
Десять лет спустя эти другие глаголы очень часто используются в RESTful API, которые поддерживают почти все сегодняшние вездесущие приложения SPA и многие мобильные приложения.
Тем не менее, интерес к REST как к структуре API начинает ослабевать с появлением GraphQL и растущим интересом к стилям функционального программирования, которые выигрывают от структур API в стиле RPC.