Статус возврата для вызова PATCH на заблокированной записи без изменений - PullRequest
Новая
       72

Статус возврата для вызова PATCH на заблокированной записи без изменений

0 голосов
/ 08 октября 2019

У меня есть RESTful API, который содержит типичный вызов PATCH, который позволяет обновлять поля при различных условиях. При некоторых условиях (конкретный статус или комбинация значений) изменения «блокируются» из записи. Если пользователь отправляет запрос PATCH на указанную запись, но PATCH не приведет к каким-либо изменениям (т. Е. Установлению значения поля на то же значение, что и раньше), какой статус должен вернуть запрос?

ДляНапример, у меня есть запись 

{
  _id: 12345,
  name: 'John Doe',
  age: 34,
  status: 'locked'
}

, и я звоню 

PATCH /users/12345
{
  age: 34
}

Поскольку статус записи «заблокирован», изменения не допускаются. Однако, поскольку тело PATCH заявляет, что значение возраста должно быть установлено равным 34, что является значением возраста для этой записи, даже если запись не была заблокирована, запрос не приведет к изменениям.

Должен ли запрос возвращать 200, потому что результат PATCH - это то, что пользователь запросил в первую очередь, или один из кодов 4xx (400, 403 или даже 409), потому что операция выполняется на «заблокированной» записи?

1 Ответ

0 голосов
/ 09 октября 2019

Если запрос вернет 200, потому что результат PATCH - это то, что пользователь запросил в первую очередь, или один из кодов 4xx (400, 403 или даже 409), потому что операция выполняется на "«заблокированная» запись?

REST - это архитектурный стиль приложения HTTP. Кэширование очень важно в REST. Семантика кэширования в HTTP описывается в RFC 7234. В частности, описывается аннулирование кэша .

Кэш ДОЛЖЕН сделать недействительным эффективный URI запроса (раздел 5.5 [RFC7230]), а также URI в полях заголовка ответа Location и Content-Location (если имеется), когда в ответ на небезопасный метод запроса получен код состояния без ошибок.

ИтакОдин из способов рассмотреть этот вопрос: если у клиента есть представление ресурса в кеше, хотите ли вы заставить клиента сделать недействительными кэшированные записи и произвести повторное получение?

Еще одна вещь, которую вы можете рассмотреть, это:не совпадают ли ваши семантики блокировки с описанными в спецификации WebDAV ;если они это сделают, возврат 423 Locked может быть разумным.

...