Почему POST предпочтительнее GET для получения списка с большим фильтром
Что проверяют
Понимаете ли вы, что здесь компромисс, а не единственно верный метод, и знаете ли, чем именно платит POST. Заодно смотрят, назовёте ли настоящую причину ограничения: не абстрактную длину адреса, а конкретные потолки на пути запроса.
Как отвечать
Аргументы за POST:
- длина. В спецификации предела нет, он есть у всех, кто стоит на пути. У Tomcat это
maxHttpHeaderSize, в Spring Boot он же настраивается черезserver.max-http-request-header-size, у nginx свои буферы заголовков, свои потолки у балансировщиков и CDN. Фильтр со списком идентификаторов пробивает их незаметно, и клиент получает 414 или 431; - структура. Вложенный фильтр с диапазонами и группами условий в строке запроса кодируется руками и разбирается руками, а телом уезжает обычным JSON, который Spring разложит в объект и проверит через
@Valid; - утечки. Адрес целиком попадает в логи доступа, историю браузера, заголовок
Refererи трассировки. Если в фильтре телефон или почта, это персональные данные в логах всех промежуточных узлов.
Сильный ответ обязательно называет цену: ответ на POST практически не кэшируется ни браузером, ни CDN, ссылку на результат не переслать и не положить в закладки, а метод по семантике не безопасный, поэтому прокси и клиенты не повторяют его автоматически. Отсюда разумный компромисс: короткие фильтры остаются на GET, сложные уходят на отдельный путь поиска, либо фильтр сохраняется отдельным запросом, а ссылка отдаётся с его идентификатором, и кэш с шарингом возвращаются.
Где спотыкаются
Называют POST безопасным способом передачи данных. Тело шифруется тем же TLS, что и адрес, никакой дополнительной защиты у него нет. Разница ровно в одном: адрес оседает в логах и истории, а тело обычно нет.
Приводят конкретное число символов как предел стандарта. Предела в стандарте нет, реальный потолок задаёт самый строгий узел в цепочке, и проверяется он замером на своём стенде, а не заученной цифрой.
Переводят на POST вообще все чтения. Список, который раньше отдавался с проверкой ETag и кодом 304, начинает каждый раз доходить до базы, а клиентские библиотеки перестают безопасно повторять запрос при обрыве.