Обновление одного объекта в REST API

При разработке нового API мы делаем все возможное, чтобы следовать шаблонам, установленным REST. Вопрос, который у меня есть, - это лучший способ отслеживания при попытке обновить одно свойство. Например:Обновление одного объекта в REST API

Представьте у вас есть простой ресурс автомобилей:

{ 
    "make": "Chevrolet", 
    "model": "Chevelle", 
    "year": 1966, 
    "color": "black", 
    "for_sale": true 
}

Давайте предположим, что свойство for_sale является то, что вы предполагаете, будет регулярно обновляться пользователем. У меня есть несколько вариантов:

PUT весь ресурс с for_sale набором для false. Для достаточно небольшого ресурса это кажется прекрасным, однако в большинстве случаев наши ресурсы достаточно велики, поэтому много отходов при отправке всего ресурса для обновления одного, часто измененного свойства.
POST и сделать частичное обновление, включая только элемент для обновления, такие как: {"for_sale":false} Это лучше, поскольку это требует намного меньше затрат.

Но я как-то, похоже, добиваюсь чего-то более простого, но, похоже, я не считаю правильный подход. Было бы довольно удобно предложить простой PUT URL-адрес (который не требует какого-либо тела запроса) для обновления этого свойства. Я вижу, что Google делает в своем API для этого, но он чувствует себя немного RPC-ish, хотя мне нравится простота.

POST/blogs/blogId/posts/postId/comments/commentId/approve (помечает комментарий не спам)

POST/blogs/blogId/posts/postId/comments/commentId/spam (помечает комментарий как спам)

Может кто-то предложить некоторые несколько советов о том, как лучше подойти к обновлению одного свойства в пределах ресурс (предпочтительно легким образом), который следовал бы принципам REST? Спасибо!

источник

2014-02-20 ski_junkie

На самом деле, я думаю, что метод PATCH разработан специально для этой цели. Вы должны использовать его для частичного обновления объекта, а не полного обновления.Here is a blog entry, что объясняет это более подробно.

источник

2014-02-20 20:55:05

Я рассмотрел обсуждение PUT vs PATCH, а также тему «частичного обновления» в этом сообщении в блоге: http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an -идиот/. В принципе, это не функция RESTful, но все равно нормально ее частично обновлять, и метод PATCH является наиболее подходящим решением. –

@WilliamDURAND, как вы говорите в своем блоге, вы можете использовать любой формат, который вы хотите для тела патча, - хотя ясно, что rfc6902 хорош - при условии, что все патчи являются простыми обновлениями и передача списка свойств = значение достаточна для решения конкретной проблема, упомянутая здесь, где нет явной потребности в полном полном протоколе diff. –

Вы должны определить, как «обновить» свойства, поэтому вам нужен формат, который определяет это, следовательно, потребность в RFC6902 или аналогичном, а не только в любом формате. Этот формат должен определять, как выполнять изменения. –

Как уже упоминалось, который:

PUT весь ресурс с for_sale значение ЛОЖЬ. Для достаточно небольшого ресурса это кажется прекрасным, однако в большинстве случаев наши ресурсы достаточно велики, поэтому много отходов при отправке всего ресурса для обновления одного, часто измененного свойства.

Это верно, так что для такого рода сценариев я предлагаю следующий подход:

URI, должно быть что-то вроде этого:

POST /api/cars/C1234

Request Body: {"for_sale":false} Как не все веб-серверы (и забыть о клиентах) поддерживают PATCH, чтобы люди поддерживали оба частичных обновления с помощью POST:

Это еще не идеальный REST но я видел и следовал за этим, как наилучшую практику.

источник

2014-02-20 15:45:35 Joshi

Обновление одного объекта в REST API

ответ

Смежные вопросы