Кратко

  • QUERY переносит выражение в содержимом запроса и зарегистрирован как безопасный и идемпотентный метод. Это обязанность реализации, а не автоматическое доказательство отсутствия бизнес-эффектов у произвольного обработчика.
  • Содержимое и его метаданные входят в ключ кеша. Повтор, перенаправления, валидаторы, Accept-Query и URI эквивалентного ресурса распределяют разные полномочия между клиентом, кешем и источником.

Представим аналитический сервис с вложенными фильтрами и сложной проекцией. GET соответствует чтению, но RFC 9110 не задаёт общей семантики для содержимого, полученного в GET. POST принимает тело, однако после обрыва соединения клиент не может по одному методу решить, не повторит ли новая отправка бизнес-действие.

Опубликованный в июне 2026 года как Proposed Standard RFC 10008 создаёт QUERY для этого промежутка. Содержимое обязательно, media type называет формат выражения, а содержимое и значимые метаданные вместе определяют вопрос целевому ресурсу. IANA регистрирует QUERY как безопасный и идемпотентный, а Accept-Query — как постоянное поле HTTP.

Это не GET с телом и не переименованный POST. Безопасность означает, что запрошенный смысл — чтение, а не изменение бизнес-состояния. Идемпотентность означает одинаковый намеренный эффект одного и нескольких идентичных запросов, а не равенство байтов ответа. Резервирование, списание, утверждение или расход права остаются небезопасными, даже если код подавляет дубль.

Свойство метода разрешает другим полагаться на него

Клиент охотнее автоматизирует безопасный метод. Транспортная библиотека может повторить идемпотентный запрос после сбоя с неизвестной точкой исполнения. Кеш применяет правила к понятному ему методу. Источник, публикующий QUERY, даёт этим участникам основание доверять заявленным свойствам.

Аннотация маршрута ещё не доказательство. Трасса должна связать метод, точный отпечаток содержимого и media type, контекст личности, исполнение приложения, эффекты и доставленное представление. При повторе она отвечает: дошла ли первая попытка до бизнес-логики и создала ли вторая запрещённое изменение?

Сопутствующая телеметрия может сопровождать чтение. Но уменьшение квоты, продвижение рабочего курсора, расход токена или внешняя команда — результат запроса. Проверять нужно последствия для пользователя и третьих сторон, а не имя функции.

Тело является частью идентичности кеша

RFC 10008 требует включать содержимое QUERY и значимые метаданные в cache key. Одинаковые метод и URI с разными телами задают разные вопросы. Ключ только по URI способен вернуть результат одного фильтра вместо другого.

Чтобы вычислить ключ, кешу может понадобиться прочитать всё содержимое. Ограничение размера, память, задержка и backpressure становятся условиями эксплуатации. Данные ушли из URI, но стали материалом идентичности в другой системе.

Кеш, понимающий media type, может нормализовать различия без семантического значения. Это отдельная власть. Удалить формально незначащий пробел — не то же самое, что отсортировать позиционный массив. Ложное совпадение возвращает неверный ответ до обращения к источнику. no-transform — инструкция HTTP, но не аудиторское доказательство отсутствия канонизации ключа.

Тесты должны идти в обе стороны: разные записи одного смысла и похожие записи разных смыслов. Числа, Unicode, повторы полей, defaults, content encoding, подписи и границы авторизации должны присутствовать. Без общего правила всех парсеров сохранение различий — обратимый выбор.

Имя продлевает жизнь результата

Эквивалентный ресурс выводится из целевого ресурса, содержимого QUERY и метаданных. Источник может назначить ему URI для последующего GET. Мимолётное выражение получает имя, которое можно копировать и хранить.

Location и Content-Location не взаимозаменяемы. В успешном ответе QUERY Location может указывать эквивалентный ресурс или ресурс запроса для GET. Content-Location соотносит возвращённое представление с URI по семантике HTTP. Обработка обоих как canonical URL стирает заявление источника о том, что именно названо.

Имя способно раскрыть вопрос. Если созданный URI содержит аккаунт или секретный фильтр, данные возвращаются в историю, журналы и ссылки. Непрозрачный идентификатор уменьшает видимость, но требует срока жизни, контроля доступа и отзыва. URI может пережить первоначальный контекст разрешения.

RFC 3986 определяет синтаксис идентификатора, но не его секретность или долговечность. Назвавший источник отвечает за последствия устойчивой поверхности.

Redirect управляет судьбой метода

При 301, 302, 307 и 308 QUERY сохраняется; исторические исключения POST не применяются. Только 303 явно переводит клиента на GET. Первая группа пересылает метод и содержимое, вторая направляет к ресурсу.

Gateway, привычно преобразующий QUERY в GET, может потерять тело или вернуть его в URI. Преобразование в POST уничтожает основание для безопасного retry. Каждый статус, смену origin, перенос credential и лимит размера нужно проверять отдельно.

В conditional QUERY валидатор относится к представлению, которое GET выбрал бы для эквивалентного ресурса. Content negotiation и авторизация сохраняются. Хеш тела вопроса не становится автоматически валидатором результата.

Accept-Query — свежий и ограниченный сигнал

Accept-Query объявляет принимаемые media types списком по RFC 9651. Сигнал распространяется на тот же path без учёта query component URI; релевантно самое новое свежее значение.

Он не доказывает валидность любого выражения или согласие всех узлов. Нужно сохранять ответ-источник поля, freshness, path и версию развёртывания.

У браузера есть ещё одна граница. QUERY не входит в CORS-safelisted methods Fetch Standard, поэтому cross-origin вызов требует preflight. Поддержки приложения недостаточно, если gateway, WAF или CORS policy не пропускает метод.

Вне URI не означает в тайне

QUERY может убрать сложные фильтры из URI-ориентированных логов и копируемых ссылок. Содержимое всё равно проходит через клиент, инструменты браузера, TLS termination, шлюзы, кеш, tracing и источник. Его могут записать, выбрать в sample и передать повторно. Redirect меняет получателя, а неудачный эквивалентный URI возвращает данные в открытую поверхность.

Различие Lu Heng между формальным контролем и практической реальностью данных здесь буквально: источник задаёт семантику, но фактическое хранение распределено между всеми получателями содержимого или отпечатка.

Его модель минимальной спецификации и локального решения сохраняет общий слой малым: метод, свойства, cache key, redirect и объявление. Языки и имена выбирает источник, отправку и повтор — клиент, корректное повторное использование — кеш.

Приоритет работающего кода указывает место доказательства. RFC фиксирует общее обещание. Только трассы подтверждают безопасность, идемпотентность, полноту ключа и неразглашающее имя.