ИИтог

HTTP QUERY: новый метод для сложных поисков в API

инфраструктураРедакция ИИтогHacker News🔥63Рейтинг ИИтог · значимость 52 · 20 баллов · 20/ч · 2 коммент.
HTTP QUERY: новый метод для сложных поисков в API

RFC 10008 определил новый HTTP-метод QUERY для выполнения сложных поисков в RESTful API. Проблема: GET с query-параметрами ломается на больших фильтрах (URL становится огромным, бывают проблемы с кодировкой и логированием), а GET с телом запроса не поддерживают многие клиенты и прокси. POST с телом работает, но он non-idempotent, что усложняет повторные попытки и кеширование.

QUERY работает как GET, но поддерживает тело запроса, остаётся безопасным и идемпотентным, кешируется (с учётом содержимого). Основной подвох: поддержка QUERY ещё очень новая и может занять годы. GET-параметры остаются нужны, особенно если пользователи должны делиться и сохранять ссылки.

Ключевые факты

  • QUERY, безопасный идемпотентный метод с телом запроса, решает ограничения GET и POST для поисков
  • Проблема старого подхода: GET с параметрами создаёт огромные URL, GET с телом не поддерживается, POST non-idempotent
  • Поддержка QUERY сейчас минимальна, может быть нужны годы, не спешите мигрировать все поиски
  • Кеширование QUERY сложнее, нужно учитывать тело запроса в ключе кеша
  • Если пользователи делятся ссылками и бумаркят результаты, остаётся GET с параметрами

Ред. Десять лет черновиков IETF, чтобы официально разрешить то, что половина индустрии давно делала через POST и стыдливо называла «поиском». Глаголов в HTTP стало больше, проблем у прокси тоже.

Почему это важно

Разработчики API за десятилетия столкнулись с дилеммой: GET не позволяет отправлять тело запроса (хотя RFC не запрещает, но многие реализации его отвергают), а POST для чтения нарушает REST-семантику. QUERY закрывает зазор, явно определив, как правильно делать сложные запросы.

Ред. Дилемму решали ровно столько, сколько люди спорили, можно ли совать тело в GET. Спойлер: можно было всегда, просто реализации делали вид, что нет.

Кому это важно

Разработчикам серверов и клиентов REST API, авторам HTTP-клиентов (браузеры, инструменты, библиотеки), создателям прокси и middleware. Особенно для тех, кто строит поиск с вложенными фильтрами, логическими выражениями или передачей структурированных данных.

Ред. Авторам HTTP-клиентов и прокси, то есть тем, кто теперь обязан это поддержать, и тем, кто будет годами ждать, пока они это сделают.

Как это применить

Постепенно, с проверкой. Для новых поисков с усложнённой логикой вместо GET с огромным query-string используйте QUERY. Следите за поддержкой в инструментах (Postman, Kreya, curl добавляют поддержку). Но если пользователи должны копировать ссылки, оставляйте GET.

Ред. «Постепенно, с проверкой» это вежливый перевод фразы «в проде встретите ровно один сервер, который умеет QUERY, и это будет ваш собственный».

Можно ли доверять

RFC 10008, это официальный стандарт, обсуждавшийся годы. Семантика четкая: QUERY = GET с телом, safe и idempotent. Однако в боевой практике это очень новое, в дикой природе почти не встречается, поэтому подводные камни могут выявиться позже.

Ред. Стандарт официальный, обсуждался годами, семантика кристальная. В дикой природе метод не встречается почти нигде, так что доверять можно ровно настолько, насколько вы доверяете обновлению корпоративного файрвола.

Риски и подводные камни

Основной риск, тонкая поддержка. Старые прокси, корпоративные файрволы и браузеры могут отвергнуть QUERY. Кеширование требует особого внимания к телу запроса в ключе. Если забыть про кеш-key, получите коллизии. Ссылки, которыми пользователи делятся, QUERY не поддерживают, поэтому для публичных фильтров остаётся GET.

Ред. Старый прокси отвергнет QUERY молча, а кеш без учёта тела в ключе выдаст вам чужой результат с уверенным лицом. Классика: новый глагол, старые грабли.

«HTTP QUERY replaces POST for read-only requests»

— RFC 10008 / креya.app