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

вопрос создан в Wed, May 8, 2019 12:00 AM

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

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

Допустим, мы хотели ПОСТАВИТЬ, ПАТЧИТЬ или УДАЛИТЬ одно из увлечений Джоуи. Как мы должны продолжать использовать API отдыха?

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

POST - /users/:id/hobbies


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


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

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

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

PATCH - /users/:id/

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

    
0
1 ответ                              1                         
  

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

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

Предполагая, что этот документ был доступен по адресу /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-код, мы бы отправили запрос с использованием идентификатора страницы, если мы захотим изменить сценарий, мы отправим идентификатор для сценария.

    
1
2019-05-08 17: 58: 33Z
источник размещен Вот