Является ли частичное представление документа допустимым «набором изменений» в соответствии с HTTP PATCH RFC?

Question

Вот что RFC 5789 говорит:

патче запросы метод, что множество изменений, описанных в запросе лица быть применены к ресурсу, идентифицированного Request-URI. Набор изменений представлен в формате, называемом «патч-документом», идентифицированным типом носителя. Если Request-URI не указывает на существующий ресурс, сервер МОЖЕТ создать новый ресурс в зависимости от типа документа патча (может ли он логически модифицировать нулевой ресурс) и разрешений и т. Д.

Разница между Запросы PUT и PATCH отражаются так, как сервер обрабатывает закрытый объект для изменения ресурса, идентифицированного Request-URI. В запросе PUT закрытый объект рассматривается как модифицированная версия ресурса, хранящегося на исходном сервере, и клиент запрашивает замену сохраненной версии. Однако с помощью PATCH закрытый объект содержит набор инструкций, описывающих, как ресурс, находящийся в настоящее время на исходном сервере, должен быть изменен для создания новой версии.

Предположим, у меня есть { "login": "x", "enabled": true }, и я хочу его отключить.

По словам Поста "Please. Don't Patch Like An Idiot.", собственно запрос PATCH будет

[{ "op": "replace", "path": "/enabled", "value": false }] 

Однако, давайте рассмотрим этот запрос:

{ "enabled": false } 

Он также «содержит набор инструкций, описывающий, как в настоящее время проживающая ресурс на сервере происхождения следует изменить ', единственное различие заключается в том, что вместо объекта JSON используется свойство JSON.

Это кажется менее сильным, но при изменении массива может потребоваться какой-то другой специальный синтаксис (например, {"a":{"add":[], "remove":[]}}), и в любом случае логика сервера не сможет обрабатывать что-либо более мощное.

Это неправильный запрос PATCH в соответствии с RFC? И если да, то почему?
А с другой стороны, был бы правильный запрос PATCH { "op": "disable" }?

Answer 1

Единственная разница заключается в том, что свойство JSON используется вместо объекта JSON.

Это на самом деле немного глубже, чем это. Важна ссылка на RFC 6902. Первый запрос имеет Content-Type из application/json-patch+json, но второй application/json

Важно то, что вы используете «дифф тип носителя,» тот, который полезен для этой цели. Вам не нужно использовать JSON-PATCH (я большой поклонник json-merge-patch), но вы не можете просто использовать все, что хотите. То, о чем вы спрашиваете во второй части, в основном: «Могу ли я создать свой собственный тип носителя», а ответ «да», просто зарегистрируйте его и зарегистрируйте его с помощью IANA.