Одни люди ищут - причины, другие - возможности, выигрывают последние

Руководство по выбору между 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 запросы используются чаще:

  1. GET запросы могут кэшироваться
  2. GET запросы могут оставаться в истории браузера
  3. GET запросы можно сохранять в своих закладках
  4. GET запросы можно передавать, распространять и т.д.
  5. 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.

Выбирая между этими двумя методами необходимо иметь некоторое чутье и я думаю следующая схема поможет Вам в этом выборе:

GET vs POST
8 комментариев на статью:
  • Евгений:

    А как же производительность ?

  • mad:

    Сразу же после правила 1 Вы ссылаетесь на RFC. Предполагаю, что речь идет о RFC-2616. Где конкретно (в каком параграфе RFC) идет речь о повторном запросе?
    Что-то не нашел.

  • Сергей:

    То что нужно, большое спасибо

  • Миша:

    Картинка все порешала. Спасибо!

  • Григорий:

    Как быть с идемпотентной модификацией данных? В этом случае запрос не должен кэшироваться. Может таки POST лучше?

    • admin:

      А почему такой запрос не должен кэшироваться, если модификация идемпотентная?
      Сервер отработал первый запрос и всё, все остальные (аналогичные) запросы ему ни к чему, так как они ничего уже не поменяют (идемпотентная модификация). По-моему будет даже лучше, если такой запрос закэшируется и не будет грузить бэкенд.
      Или я Вас неправильно понял?

Ответить
Обязательные поля помечены *