Как POST, PATCH и DELETE элементы из массива вложенных документов, используя REST - PullRequest
Новая
       22

Как POST, PATCH и DELETE элементы из массива вложенных документов, используя REST

0 голосов
/ 08 мая 2019

Допустим, у нас был следующий пользовательский документ: 

{
  "_id": "1",
  "firstName": "Joe",
  "hobbies": [
     "_id": "1",
     "name": "music",
     "talented": true
   ],
}

Итак, скажем, мы хотели POST, PATCH или DELETE одно из хобби Джои.Как мы должны продолжать использовать API отдыха?

Я думал о том, чтобы сделать что-то вроде этого: 

POST - /users/:id/hobbies


PATCH - /users/:id/hobbies/:id


DELETE - /users/:id/hobbies/:id

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

Итак, я подумал иначе, просто сделать патч к основному документу пользователя:

PATCH - /users/:id/

Какая структура маршрута отдыха подходит для выполнения этих задач?

1 Ответ

1 голос
/ 08 мая 2019

Допустим, у нас был следующий пользовательский документ. Как нам продолжить использовать api rest?

Обрабатывая документ как документ: внесите изменения локально и отправьте результат обратнона сервер.

Предполагая, что этот документ был доступен на /users/1/, мы просто отправили бы обратно представление с удаленным хобби ... 

PUT /users/1/

{
  "_id": "1",
  "firstName": "Joe",
  "hobbies": [
   ],
}

Использование PATCH вместо PUT - этохорошо (при условии, что мы отправляем патч-документ как тело сообщения).Технически, вы также можете использовать POST, но POST здесь на самом деле не дает вам никаких преимуществ. 

/users/:id/hobbies
/users/:id/hobbies/:id

Проблема с использованием таких идентификаторов заключается в том, что клиенты общего типа не признают, что им есть что-тоделать с /users/:id/ - поэтому, даже если вы отправите сообщение об удалении хобби, локально кэшированная копия клиента не будет обновлена ​​(поскольку использует другой ключ).

Теперь, если ваши ресурсы были спроектированыиспользуя ссылки 

{
  "_id": "1",
  "firstName": "Joe",
  "hobbies": [ { "href": "/users/1/hobbies/4" } ]
}

Тогда мы все равно будем использовать /users/1/ для добавления / удаления хобби из коллекции, но если мы захотим изменить представление самого хобби, то мы быотправлять сообщения, используя /users/1/hobbies/4.

Если бы сама коллекция хобби была ссылкой ... 

{
  "_id": "1",
  "firstName": "Joe",
  "hobbies": "/users/1/hobbies"
}

Тогда мы добавляли / удаляли хобби, отправляя сообщения на /users/1/hobbies.

Это может помочь подумать о веб-страницах - HTML-представление веб-страницы часто будет содержать ссылки на изображения или сценарии, которые извлекаются и кэшируются отдельно от самой страницы.Если бы мы хотели отредактировать HTML, мы бы отправили запрос с использованием идентификатора страницы, если мы захотим изменить скрипт, мы бы отправили идентификатор для скрипта.

...