Кратко

  • RFC 9110 называет токен метода главным источником семантики запроса: он показывает цель клиента и ожидаемый успешный результат, а каждый ресурс отдельно решает, распознаёт, реализует и допускает ли этот метод.
  • Safe ограничивает запрошенное намерение, но не устраняет все побочные эффекты. Idempotent ограничивает предполагаемый эффект повтора, но не требует одинаковых ответов, журналов или внешних последствий.
  • Надёжная квитанция объединяет метод, цель, аутентифицированного принципала, авторизацию, предусловие, неопределённость первой попытки, прикладную идемпотентность, автора повтора, ответ, итоговое состояние и последствия.

PUT выглядит как команда. В HTTP это прежде всего публично понятное описание намерения. Благодаря ему кэш отличает получение от изменения, шлюз применяет ограничение, а клиент оценивает повтор после обрыва соединения. Им не требуется видеть бизнес-логику целиком.

Но слово не отвечает, знает ли сервер PUT, поддерживает ли его этот ресурс, имеет ли текущий принципал право, осталась ли версия актуальной и успела ли первая попытка совершить commit. Если все эти вопросы заменить глаголом, расследовать отказ или дубликат будет невозможно.

Единый интерфейс видит цель, но не решает допуск

RFC 9110 определяет метод через назначение запроса и результат, который клиент считает успешным. GET просит текущее представление. PUT просит создать или заменить представленное состояние по выбранному адресу. DELETE просит убрать связь между URI и его текущей функцией; он не обещает физически уничтожить все хранимые данные.

Стандартизованный метод должен сохранять смысл на разных ресурсах. Так общие компоненты делают ограниченные выводы без закрытого знания приложения. Однако ресурс сам выбирает реализацию и допуск. Неизвестный или нереализованный метод ведёт к 501. Известный и реализованный, но не поддерживаемый целью, ведёт к 405 с текущим Allow.

Allow описывает функциональную поверхность, а не круг уполномоченных лиц. Документ может поддерживать PUT только для редактора. Аутентификация определяет принципала, авторизация применяет политику к принципалу, действию и цели, поддержка метода описывает способность ресурса. Это три самостоятельных решения.

В терминах Minimum Initial Specification Heng Lu общая часть строго фиксирует только смысл, необходимый для совместимости. Деловая политика остаётся у участников, запускающих ресурс. Реестр IANA — ledger словаря, а не центральный сервер прав.

Safe распределяет ответственность, но не отменяет последствия

Безопасный метод по определённой семантике в основном предназначен для чтения: клиент не просит изменить состояние origin server. RFC 9110 тут же уточняет, что сервер может записать лог, рекламный переход может списать средства, а реализация — создать иные эффекты. Клиент их не запрашивал, поэтому ответственность нельзя автоматически переложить на него.

Эта граница позволяет индексаторам, проверке ссылок и предварительной загрузке работать. Владелец ресурса обязан запретить опасное действие под безопасным методом. GET к page?do=delete не должен удалять данные. Команда в query-параметре не превращает обход ссылок в волю пользователя.

Аудит хранит две колонки: изменение, которого просил клиент, и действия, добавленные сервером. Логи, биллинг, квота, отслеживание и внешнее уведомление относятся ко второй. Safe также не означает открытый доступ: чтение конфиденциального документа остаётся объектом авторизации.

Idempotent означает сходящийся замысел, а не одинаковую историю

Метод идемпотентен, если несколько одинаковых запросов имеют тот же предполагаемый эффект на сервере, что и один. RFC 9110 относит сюда PUT, DELETE и безопасные методы. Сервер всё равно может отдельно записать каждую попытку, создать несколько ревизий и вернуть разные ответы.

После успешного DELETE повтор может обнаружить отсутствие ресурса. Повтор PUT может прийти к тому же состоянию с другой датой или ETag. Сходится требуемый эффект, а не весь окружающий мир.

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

Поэтому нужны стабильный operation key, состояние commit, дедупликация на каждой границе и компенсация. Идемпотентность протокола — отправная точка рассуждения, а не распределённая транзакция.

Повтор начинается с неизвестности первой попытки

При обрыве до ответа клиент может не знать, дошёл ли запрос, был ли применён или потерялся лишь ответ после commit. Идемпотентный запрос разумно повторить, потому что вторая попытка должна привести к тому же предполагаемому эффекту, даже если первая уже сработала.

RFC 9110 не разрешает бесконечный цикл. Неидемпотентный метод не следует автоматически повторять без знания, что конкретная операция сходится на этом ресурсе, или доказательства, что первый запрос не был применён. Прокси не вправе автоматически повторять такие запросы. После неудачного автоматического повтора не должна начинаться новая автоматическая цепочка.

Квитанция восстановления включает точку обрыва, цель, hash содержимого, предусловие, прикладной ключ, доступный для запроса статус, номер попытки и backoff. POST со стабильным идентификатором может восстанавливаться безопасно. PUT с неконтролируемыми внешними эффектами — нет.

Running-Code Primacy возвращает проверку к наблюдаемому поведению: действительно ли дубликаты сходятся, можно ли независимо прочитать commit, ограничены ли последствия. Метка ценна только вместе с работающим доказательством.

If-Match защищает версию, а не личность

If-Match требует, чтобы текущий ETag по-прежнему совпадал с известным клиенту перед изменением. При ложном условии метод не выполняется и обычно возвращается 412. Так старая копия не затирает новую правку.

Знание ETag не даёт права записи. Право записи не обновляет устаревший ETag. Авторизация отвечает, может ли принципал действовать; предусловие — существует ли ещё предполагаемое состояние. Причины отказа должны сохраняться отдельно.

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

QUERY делает частное знание общей семантикой

RFC 10008, опубликованная в июне 2026 года Julian Reschke, James Snell и Mike Bishop, определяет QUERY. Fielding не является её автором. QUERY переносит содержимое как POST, но объявляет безопасный и идемпотентный запрос. IANA отмечает обе характеристики как yes.

Сложные запросы неудобно помещать в URI: они бывают длинными и попадают в журналы или историю. Поэтому приложения часто читают через POST. Общий посредник не знает, что именно этот POST безопасен и повторяем. QUERY делает намерение видимым, оставляя ресурсу смысл содержимого и решение о поддержке.

Регистрация не равна внедрению. Шлюз может не пропустить метод, сервер ответит 501, ресурс — 405, политика — отказом в доступе. Реестр является таблицей значений, а не ACL.

Вклад Fielding — граница интерфейса, а не владение

IETF Datatracker, проверенный 31 августа 2026 года, описывает Roy T. Fielding как Senior Principal Scientist в Adobe, сооснователя The Apache Software Foundation, автора REST и участника стандартов HTTP, URI и URI Templates. Он перечисляет 18 RFC и роль рецензента HTTP Directorate. UC Irvine фиксирует его степени и вклад в Web, REST и Apache.

Его диссертация рассматривает единый интерфейс как ограничение REST, улучшающее наблюдаемость, повторное использование, масштабирование и независимое развитие ценой части эффективности специального интерфейса. Словарь методов воплощает этот обмен: общий замысел виден, хранение, политика и выполнение остаются локальными.

У RFC 9110 три редактора: Fielding, Mark Nottingham и Julian Reschke. HTTP — коллективная и развивающаяся работа. RFC 10008 принадлежит указанным авторам. Подпись делает вклад прослеживаемым, но не создаёт собственность на протокол.

Полная квитанция начинается за пределами метода

Записываются метод, URI и origin, аутентифицированный принципал и scope, поддержка ресурса, решение и версия политики, ETag, hash содержимого и предполагаемый эффект. После сбоя добавляются последняя подтверждённая точка передачи, возможность применения первой попытки, operation key, автор, причина, номер и пауза повтора.

Затем фиксируются ответ, повторно прочитанное состояние, внешние эффекты, компенсации и необратимость. Метод отвечает, чего хочет клиент. Ресурс — понимает ли он запрос. Политика — вправе ли этот принципал действовать. Предусловие — актуально ли состояние. Доказательства восстановления — оправдан ли повтор.

Метод называет намерение. Он не выдаёт разрешение.

Источники