⚡️Новости из мира RFC: появился новый HTTP метод QUERY Последний раз такое было в марте 2010 года, когда нам подарили метод PATCH (им вообще кто-то пользуется?). С тех пор утекло много воды, и вот комитет IETF официально утвердил новый стандарт — метод QUERY(RFC 10008).

Зачем нужен еще один метод, если у нас есть GET и POST для запроса данных с фильтрацией? Давайте разбираться.

🛠 В чем главная боль старого подхода? Когда вам нужно получить отфильтрованные данные с сервера, вы используете GET. Но у него есть две огромные проблемы:

• Лимит на размер. Параметры пишутся прямо в URL. Если фильтр сложный, адресная строка быстро упирается в лимит и падает с ошибкой.

• Безопасность. Все, что вы передаете в URL, оседает в логах прокси-серверов, браузеров и самого бэкенда. Передавать туда сенсетив данные — плохая идея.

Как решали раньше? Использовали POST. Но это концептуальный костыль. POST по своей сути должен создавать или изменять данные, поэтому такие запросы не кэшируются.

🚀 Что делает новый метод QUERY? Метод QUERY объединил в себе лучшее от двух миров:

• Как у POST: он позволяет передавать параметры запроса (JSON, XML или обычный query string) в теле. А это значит, что мы избегаем километровых URL.

• Как у GET: этот метод безопасен для состояния сервера (он ничего не меняет) и идемпотентен. А главное — ответы на запросы QUERY можно кэшировать! Ключом же будет адрес + тело запроса

📝 Как это выглядит на практике? Вместо некрасивого: GET /users?status=active&role=admin&secret_token=123...

Мы пишем аккуратный запрос: QUERY /users HTTP/1.1 Host: api.example.com Content-Type: application/json

{ "status": "active", "role": "admin", "secret_token": "123" }

📅 Когда переезжаем? Стандарт уже официально опубликован, но внедрение будет постепенным. И бонус-посыл: готовьтесь, где-то в ближайшем будущем нас ждут вопросы по новому методу на собеседованиях. Ведь быть в актуальных новостях - это тоже + балл кандидату.