Как передавать данные в GET и POST запросах

Что проверяют

Понимаете ли вы, где данные видны и логируются, и знаете ли последствия для безопасности и кеширования.

Как отвечать

GET передаёт данные в адресе: путь и параметры запроса. POST передаёт их в теле, а формат объявляется заголовком типа содержимого.

Практические различия:

• видимость: адрес попадает в историю браузера, логи сервера и прокси, заголовок Referer. Поэтому токены, пароли и персональные данные в параметрах передавать нельзя, только в теле;
• длина: жёсткого предела в спецификации нет, но на практике адреса длиннее нескольких тысяч символов режутся серверами и прокси. Большой фильтр или список идентификаторов уходит в тело;
• кеширование: ответы на GET кешируются браузером и промежуточными узлами, ответы на POST нет. Отсюда и правило: GET не должен менять состояние;
• идемпотентность: повтор GET безопасен, повтор POST может создать вторую сущность, поэтому в важных операциях применяют ключ идемпотентности;
• форматы тела: JSON для API, форма для классических форм, многочастная форма для файлов.

Для тестировщика важное: проверить поведение при отсутствии обязательных параметров, при неверном типе содержимого (должен быть 415, а не 500), при слишком длинном адресе, при повторной отправке формы. И помнить, что GET с телом формально возможен, но многие прокси его отбрасывают, поэтому API так строить не стоит.

Где спотыкаются

Передают токен в параметрах адреса и утекают его в логи.

Делают удаление через GET, после чего краулер или предзагрузка ссылок удаляют данные пользователей.

Не проверяют повторную отправку POST и пропускают дублирующиеся заказы.