REST API - обновление отношений между сущностями - PullRequest
Новая
       33

REST API - обновление отношений между сущностями

0 голосов
/ 08 февраля 2020

Вот как вы добавляете книгу к автору в моем API: 

PUT /authors/1/books/1/

Теперь я хочу изменить книгу на другого автора.

Как я могу это сделать? Я думаю о следующих вариантах.

1- Создание / авторов и / книг как ресурсов верхнего уровня. Управляйте автором книги, используя свойство книги, например authorId: 2. Например, PUT /book/1 и установите authorId: 2 в теле с другими атрибутами.

2 - Выполните PUT /authors/2/books/1/, изменив существующую книгу автора на 2. С помощью этого метода я должен проверить, существует ли книга уже , Если существует, я обновляю автора и другие атрибуты, если нет, я бы создал новую книгу.

Какой из вариантов был бы наилучшим с точки зрения передового опыта? Второй вариант - чепуха?

Ответы [ 3 ]

1 голос
/ 09 февраля 2020

Хорошо, позвольте мне предположить что-то ..

  • одна книга один автор
  • у вас уже есть идентификатор книги, потому что он идет первым в вашем утверждении, верно
  • у вас уже есть идентификатор автора, который вы хотите установить

Затем позвольте мне навязать что-то .. 

POST /books/1
{
  op: 'set'
  entity: 'authorId'
  value: 2
}

(я не говорю, что это лучшая практика, просто пример )

1 голос
/ 09 февраля 2020

URI - это идентификатор - с точки зрения компонентов общего назначения он семантически непрозрачен. Информация о текущем состоянии ресурса выражается в представлении, а не в идентификаторе.

Теперь я хочу сменить книгу на другого автора.

Как на клиенте, обычный способ сделать это - загрузить копию представления книги, изменить локальную копию для ссылки на нового автора, а затем отправить запрос PUT для того же целевого URI, который вы использовали для получения представления , Семантика PUT просит сервер изменить представление сервера целевого ресурса в соответствии с клиентом.

Сервер может кодировать информацию в URI, но эта информация предназначена исключительно для использования сервером.

Что, да, означает, что потенциально клиент может вносить изменения в представление, которые конфликтуют с "семантикой", выраженной в URI. Это аналогично ситуации, когда имя файла и его содержимое не выровнены.

Сервер, поняв семантику запроса общего назначения, может затем решить, что с ним делать. Разумные варианты включают

  • Отклонение запроса
  • Принятие изменений на месте, оставление разногласий между идентификатором и представлением
  • Принятие этих изменений в каком-то другом месте эффективное создание (или редактирование) нового ресурса.

Последний вариант, пожалуй, самый сложный, чтобы понять, как настроить клиент общего назначения для соответствия его пониманию обновленной модели ресурсов сервера.

1 голос
/ 09 февраля 2020

Оба идентифицируются однозначно, поэтому оба должны быть ресурсами сами по себе, т.е. 

GET /authors/1
GET /books/1

Поэтому второй вариант, который вы предлагаете IMO, кажется наиболее разумным, т. Е. 

PUT /books/1

{ authorId: 2 }
...