Лучшая практика REST для обновления элемента в массиве элементов - PullRequest
0 голосов
/ 12 октября 2019

В моем одностраничном приложении, которое использует сервисы RESTful, я хочу знать, как лучше всего обновлять один элемент в массиве элементов.

Предварительные условия
1. Front-end делает запрос GET для получения списка элементов
2. Front-end форматирует список элементов (т.е. конвертирует даты из UTC в местное время)
3. Front-end делает запрос PUT длясерверная часть для обновления имени элемента

возможные решения

решение № 1
4. серверная часть отвечает HTTP-200 и обновляется одинitem
5. Front-end переформатирует обновленный элемент
6. Front-end объединяет список элементов, находит и заменяет обновленный элемент

PRO
-Один API-запрос на обновление элемента
CON
- Дублирование данных во внешнем интерфейсе, без единого источника правды (то есть списка элементов)


Решение # 2
4. Серверная часть отвечает HTTP-200 и обновленным списком элементов
5. Интерфейс переформатирует список элементов

PRO
- Один запрос API для обновления элемента
CON
- Неследуйте принципу единой ответственности (т.е. API для обновления элемента обновляет один элемент и возвращает все элементы)


Решение # 3
4. Внутренний ответс HTTP-200 и одним обновленным элементом
5. Front-end делает запрос GET для извлечения всех элементов
6. Front-end форматирует список элементов

PRO
- Более гибкие для будущих реализаций, API-интерфейсы следуют принципу единой ответственности
CON
- Два запроса API на обновление элемента

Ответы [ 2 ]

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

Я хочу знать, как лучше всего обновлять один элемент в массиве элементов.

Важно понимать, что такое REST, или HTTP, что мы разрабатываемсообщения для использования компонентами общего назначения. То есть мы используем легко стандартизированные формы для передачи семантики.

HTTP PUT имеет семантику загрузки документа в хранилище документов. Для вашего примера, где мы ПОЛУЧАЕМ представление ресурса списка, вносим локальные изменения и PUT результат, полезная нагрузка PUT является копией complete представления ресурса -мы просим, ​​чтобы сервер сделал свою копию похожей на копию клиента.

Предполагая, что сервер решает применить новое представление к своей копии ресурса, полезная нагрузка ответа может быть сообщением о состоянии. («Это сработало»), или копия нового представления ресурса, или даже пустой документ ( 204 No Content ) с метаданными, описывающими новое представление ресурса (и подразумевается, чтосервер принял представление клиента без изменения ).

Однако ключевая идея PUT заключается в том, что полезная нагрузка представляет собой полное представление ресурса, а не простоописание изменений, внесенных в него. Если документ очень большой (в частности, большой по сравнению с заголовками HTTP), и редактирование, которое вы делаете, невелико, то вы можете отправить патч-документ с описанием изменений, которые вы внесли в документ, указав *Метод 1025 * PATCH в запросе.

Конечно, в Интернете самый популярный формат документов не включал поддержку гипермедиа для PUT или PATCH, а самыми популярными клиентами были браузеры, а не документы. редакторы, поэтому мы должны были разработать наши протоколы изменений около POST. Так что это тоже нормально, нужно просто подумать о том, как представления данных формы будут применяться к ресурсу.

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

Решение 2 следует принципу единой ответственности, вы можете быть озадачены именами и «ответственностью», но если мы рассмотрим истинное определение SRP: «единственная причина изменения», решение 2 вполне подойдет и предпочтителен, еслипроизводительность не критична.

https://deviq.com/single-responsibility-principle/

...