ИИтог

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

инфраструктураРедакция ИИтогHacker News🔥63Рейтинг ИИтог63

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 с параметрами

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

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

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

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

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

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

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

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

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

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

«HTTP QUERY replaces POST for read-only requests»

— RFC 10008 / креya.app