REST API - Обработка пустого тела в PATCH

Question

В настоящее время я участвую в разработке REST API, написанного на Go, и столкнулся с экзистенциальным вопросом.

Как мы должны обрабатывать пустое тело в патче?Зная, что PATCH используется для обновления существующих данных, мы должны возвращать код ошибки (4XX) или статус ok (2XX)?

Например, если у меня есть следующий маршрут: /user/:id

И у пользователя есть следующая структура:

type User struct {
  Name string
  Email string
}

Так что, если мы УБИРАЕМ определенного пользователя, у нас будет либо тело, содержащее имя или адрес электронной почты.

Что нам делать, если он пуст?

RFC5789 не помог (2.2 для обработки ошибок)

https://datatracker.ietf.org/doc/rfc5789/?include_text=1

Заранее большое спасибо!

Answer 1

Как мы должны обрабатывать пустое тело в патче?

Это зависит: что не так с пустым телом патча?

Если пустое тело патчаявляется ошибкой, тогда ваш ответ должен сообщать клиенту природу ошибки.

Если пустое тело исправления не является ошибкой, примените пустое исправление.Это, вероятно, нет операции, в этом случае, успех!Таким образом, вы возвращаете ответ, который объясняет, что применение пустых исправлений тривиально, и здесь они могут увидеть обновленную реализацию.Кроме того, вы можете 204, как показано в примере.Я не вижу явных разъяснений, но я думаю, что вы можете использовать шаблон, описанный в RFC 7231 section 6.3.1 .

Некоторые примеры, которые могут помочь.

Предположим, что клиент использовал JSON Patch в качестве типа носителя для запроса.Теперь «документ JSON Patch - это документ JSON [RFC4627], представляющий массив объектов».Пустое тело запроса не является допустимым документом JSON и, конечно, не является допустимым массивом объектов, так что это искаженный документ патча , и, как описано в разделе 2.2, вы должныдумал об отправке ответа 400.

Предположим, что клиент должен был отправить патч json с пустым массивом операций

[]

Семантически, это неоперация - , за исключением что ответ, указывающий, что исправление было успешно применено, сделает недействительными кэшированные значения.Таким образом, вы, безусловно, можете сообщить об успехе (200), ничего не делая.Вы можете быть в состоянии предотвратить аннулирование кэшированных записей, возвращая ошибку (я думаю, что спецификация Patch не совсем правильно описывает семантику, но я не вижу поданных ошибок).

Аналогичный аргумент применяется для application / merge-patch + json .

Вы также можете рассмотреть опечатки для RFC 5789

Если сервер получает запрос PATCH с типом носителя, спецификация которого не определяет семантику, специфичную для PATCH, серверу СЛЕДУЕТ отклонить запрос, возвращая код состояния 415 Unsupported Media Type, если только не требуется более конкретный код состояния ошибкиpriority.

В частности, серверам НЕ СЛЕДУЕТ использовать семантику PATCH для универсальных типов носителей, которые их не определяют, таких как «application / xml» или «application / json».