Кратко

  • Accept-Patch перечисляет медиатипы, принимаемые ресурсом как документы исправления. Наличие поля указывает возможность PATCH, но не аутентифицирует клиента, не выдаёт право записи и не проверяет конкретное изменение.
  • Обнаружение, язык документа, условие состояния и авторизация — четыре самостоятельных решения. Объявление помогает подготовить запрос; остальные вопросы решаются только для реально поступившего запроса.

В ответе OPTIONS указаны application/json-patch+json и application/merge-patch+json. Клиент узнал о двух грамматиках. Он не узнал, разрешена ли запись его учётной записи, актуальна ли прочитанная версия и допустимы ли операции по правилам приложения. Полномочий он не получил.

Ошибка возникает, когда формальное объявление превращают в единый флаг «можно редактировать». Accept-Patch исходит от сервера, зарегистрирован и часто соседствует с Allow. Однако RFC 5789 отдельно определяет список форматов и отдельно требует авторизовать PATCH.

Возможность ресурса не равна праву субъекта

PATCH стандартизован потому, что PUT означает полную замену, а частичное изменение требует инструкций, смысл которых задаёт медиатип. Целевой URI выбирает ресурс, Content-Type — язык, условие связывает действие с наблюдавшимся состоянием, а аутентификация и контроль доступа решают вопрос о субъекте.

Accept-Patch предшествует этим проверкам. Он содержит список медиатипов с возможными параметрами и должен появляться в OPTIONS для ресурса с PATCH. В ответе на любой метод поле неявно сообщает поддержку PATCH для данного URI; каждый элемент объявляет принимаемый формат.

Слово «разрешён» относится к протокольной возможности. Раздел безопасности RFC 5789 отдельно требует авторизации, доступа и аутентификации. Поэтому публичный GET может показывать список, а анонимный PATCH — получать 401 или 403. Одинаковое объявление не означает одинаковый диапазон полей для разных аккаунтов.

PATCH может находиться в Allow без Accept-Patch: метод известен, форматы нет. RFC 9110 добавляет, что фактический набор методов определяется при каждом запросе и может меняться. Наблюдение не является арендой возможности.

Медиатип задаёт программу

Обязательного формата по умолчанию нет. Сервер обязан проверить применимость документа. Проверенная errata 3169 подчёркивает: семантика PATCH берётся из медиатипа. Умение разобрать application/json либо application/xml не даёт права придумать частный язык изменения.

JSON Patch использует application/json-patch+json и упорядоченные add, remove, replace, move, copy и test. JSON Merge Patch использует application/merge-patch+json, по форме похож на цель, определяет добавление и замену сравнением и отводит null значение удаления.

Оба работают с JSON, но не взаимозаменяемы. test проверяет отдельную гипотезу; Merge Patch краток для объектов, однако неудобен при значимом null и точном изменении массивов. Совместное объявление не разрешает автоматическое преобразование и не задаёт предпочтение порядком.

Клиент выбирает язык осознанно и указывает Content-Type. Смена ярлыка готового тела не меняет грамматику.

Объявление встречается и при отказе

Поддерживаемый формат не гарантирует успех. Плохая структура может дать 400, неподдерживаемый тип — 415, корректные, но невыполнимые инструкции — 422. Для отсутствующей неподходящей цели возможен 404, для конфликта состояния — 409, для ложного условия — 412.

Ответ 415 должен включать Accept-Patch. Сервер отказывает и одновременно сообщает альтернативы. Поле не принимает прежний запрос, не позволяет сменить только Content-Type и не обещает прохождение доступа и бизнес-правил.

Клиент сохраняет отказ и локально решает, способен ли построить новую эквивалентную операцию. Это новый запрос в новом состоянии. Обнаружение уменьшает догадки, но не приказывает повторять.

If-Match защищает состояние

Документ на известной базе может повредить ресурс после конкурентного изменения. RFC 5789 рекомендует условный запрос и сильный ETag в If-Match.

RFC 9110 требует сильной проверки If-Match до метода. Несовпадение даёт 412 и не заставляет сервер угадывать новое наложение. Но ETag не является удостоверением: его может знать субъект без прав, а субъект с правами может прислать устаревшее значение. Состояние и доступ проверяются раздельно.

IANA регистрирует PATCH как небезопасный и неидемпотентный. Конкретный документ иногда можно сделать идемпотентным, но это зависит от операций. Accept-Patch не говорит, что произойдёт при повторе будущего тела.

Атомарность относится к исполнению

Сервер применяет весь набор либо ничего. Промежуточное состояние нельзя показывать, а при ошибке ни одна часть не остаётся. RFC 6902 демонстрирует это провалом test, отменяющим весь JSON Patch.

Гарантия действует после допуска запроса и не выдаётся объявлением. PATCH способен иметь прикладные эффекты на другие ресурсы, поэтому граница фиксации охватывает непосредственно затронутое.

Чёткая обработка аутентифицирует, авторизует цель и операции, проверяет Content-Type, разбирает нужный язык, оценивает If-Match и правила домена, затем фиксирует атомарно. Чтение Accept-Patch не начинает транзакцию и не ставит блокировку.

Кэш и подпись не расширяют поле

RFC 9111 требует от прошедшего кэша инвалидировать цель после неошибочного ответа на небезопасный метод. Same-origin Location и Content-Location могут быть кандидатами, чужой origin — нет. Это следствие реального PATCH, не OPTIONS с объявлением, и оно не гарантирует глобального удаления.

RFC 9421 позволяет подписать выбранные компоненты. Покрытие Accept-Patch защищает целостность и подлинность в рамках профиля, но не создаёт решение о доступе. Для связывания личности, метода, цели и содержимого нужен дополнительный протокол.

Проверяемая модель

Клиенту следует раздельно хранить URI и время наблюдения, сигнал метода, типы и параметры, валидатор исходной версии и контекст учётных данных. Сервер объявляет способность, а при PATCH отдельно проверяет личность, доступ, формат, условие и атомарное исполнение.

Тесты должны включать Allow без списка, список в GET, одинаковую рекламу при разных правах, старый If-Match, отказ generic JSON, различные эффекты двух форматов, провал test без изменений и подписанное объявление с последующим 403.

Текущая errata содержит три проверенные записи и одну отклонённую. 5521 удаляет Content-Location из примера 204, 7513 исправляет только ссылку, а отклонённая 3419 не меняет стандарт.

Источники