Руководство по выбору между GET и POST
Перевод: The Definitive Guide to GET vs POST
Думаю данная статья для многих не откроет Америки, и мне она показалась какой-то немного сумбурной, поэтому пришлось ее местами сглаживать, но в качестве вводной для выбора между использованием GET или POST запроса, думаю это - то самое.
К сожалению на практике встречается множество несостыковок в использовании GET вместо POST и наоборот. Оба HTTP метода могут приводить к одинаковым результатам, но их некорректное использование может привести к неожиданным и потенциально опасным последствиям.
Поэтому, что-бы быть уверенным в том, что мы делаем все правильно, я представляю Вам руководство по выбору между GET и POST.
Давайте вспомним, что в строках запросов, пара переменная/значение, передается в GET через вот такой URL запрос:
GET /blog/?name1=value1&name2=value2 HTTP/1.1
Host: carsonified.com
а в POST запросе она передается в теле заголовка:
POST /blog/ HTTP/1.1
Host: carsonified.com
name1=value1&name2=value2
Основы: GET против POST
Давайте введем новое слово в свой словарный запас, термин - идемпотентный (Вам не стоит лезть в википедию за его трактовкой: идемпотентность это свойство объекта проявляющееся в том, что повторное действие над этим объектом не изменяет его), а разделы 9.1, 9.3 и 9.5 RFC 2616 помогут нам составить первое правило GET против POST...
Правило #1: Используйте GET для безопасных действий и POST для небезопасных
RFC указывает Интернет браузерам на то, что пользователей необходимо предупреждать о повторном использовании POST запроса, потому что это действие потенциально небезопасно (к примеру оформление онлайн оплаты).
Однако, пока браузер соблюдает это требование RFC, может поясним почему POST должен использоваться для небезопасных действий, и почему мы не должны использовать POST для безопасных?
Просто примите к сведению то, что GET запросы используются чаще:
- GET запросы могут кэшироваться
- GET запросы могут оставаться в истории браузера
- GET запросы можно сохранять в своих закладках
- GET запросы можно передавать, распространять и т.д.
- GET запросы можно легко изменять
Примечание: Если Вам необходимо извлекать лучшее из обоих методов, небезопасное действие можно превратить в безопасное сделав его идемпотентным и таким образом обезопаситься от возможной проблемы многочисленных повторений запросов. Вы назначаете каждому запросу свой уникальный ID и проверяете его на сервере, был ли запрос с таким ID обработан ранее. На самом деле все небезопасные действия должны быть идемпотентными, так как пользователя не остановят никакие предупреждения.
GET против POST: копаем глубже
Правило #2: Используйте POST для операций с важной информацией
Так как в GET запросах строка запроса находится в открытом виде, мы должны заботиться о своей безопасности и о том, что пользователи будут работать с важными данными, такими как пароли или номера кредитных карт:
1. Наши пользователи могут и не догадываться об этом, передавая важные данные через URL другим лицам или когда история серфинга в их браузере может быть просмотрена другими пользователями этого компьютера (хотя это может и не сработать при работе с AJAX ориентированными сервисами).
2. Мы сами нарушаем закон о частной информации, сохраняя, к примеру, в логах своего сервера номера CV2s с кредитных карт пользователей.
Правило #3: Используйте POST для операций с большими данными
Несмотря на то, что RFC не описывает такой параметр, как длина URL, Internet Explorer упорно придерживается мнения, что максимальная длина URL не может превышать 2,048 символов, это накладывает некоторые ограничения на использование GET.
Правило #4: Используйте GET в AJAX приложениях
Когда используется XMLHttpRequest, браузеры реализуют POST как двухпроходный процесс (сперва посылают заголовок, а затем данные). Это означает, что GET запросы более отзывчивые, что так необходимо для хорошего AJAX окружения.
Итоги
Хотя правила обычно существуют для убедительных причин, хорошо бы знать то, что за ними скрывается. Я сам ненавижу правила, у которых нет объяснений и надеюсь, что все вышесказанное поможет Вам уяснить правила различий GET против POST.
Выбирая между этими двумя методами необходимо иметь некоторое чутье и я думаю следующая схема поможет Вам в этом выборе:

А как же производительность ?
А можно более подробно развернуть вопрос?
Сразу же после правила 1 Вы ссылаетесь на RFC. Предполагаю, что речь идет о RFC-2616. Где конкретно (в каком параграфе RFC) идет речь о повторном запросе?
Что-то не нашел.
Это вытекает из требований параграфа 9.1.1 Safe Methods (об это и сказано в статье)
То что нужно, большое спасибо
Картинка все порешала. Спасибо!
Как быть с идемпотентной модификацией данных? В этом случае запрос не должен кэшироваться. Может таки POST лучше?
А почему такой запрос не должен кэшироваться, если модификация идемпотентная?
Сервер отработал первый запрос и всё, все остальные (аналогичные) запросы ему ни к чему, так как они ничего уже не поменяют (идемпотентная модификация). По-моему будет даже лучше, если такой запрос закэшируется и не будет грузить бэкенд.
Или я Вас неправильно понял?