Создание отношения сущности в REST: Могу ли я создать родителя, опубликовав идентификатор ребенка?

В настоящее время мы разрабатываем REST API для доступа к классическим данным клиентов. Одним из элементов API являются активы пользователя. Активы добавляются в рамках данной услуги. Внутренний API добавит ресурс только пользователю в рамках данной службы. Таким образом, нет отношения Пользователь - Актив, но есть отношение Пользователь - [Сервис] - Актив.

Наши URI будут выглядеть так:

/users/{id}/assets/{id}/services/{id}

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

Одним простым способом было бы опубликовать все отношение к /users/{id}/assets/

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

но тогда мы на самом деле не создаем актив, как может указывать URI, но отношение актив-сервис.

В качестве альтернативы, мы рассматриваем POST'ing для URI, адресующего отношение, например:

POST /users/{id}/assets/{id}/service/{id}
{attribute1:"{var}", attribute2:"{var}"}

Но в этом случае путь ресурса /users/{id}/assets/{id}не будет существовать до POST и будет создан как побочный эффект.

POST'ing к пути ресурса, который еще не существует вообще?

Спасибо за ваши мысли,

Джерард.

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

Если вы спрашиваете, является ли этот тип шаблона создания при доступе допустимым, приемлемым шаблоном разработки, ответ будет «да, это так» - это и допустимый, и довольно распространенный шаблон, который можно увидеть.

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

Второе: ваш JSON неверен, вам приходится иметь дело со службой как с другим объектом внутри объекта актива, так же как и с сервисами URI ресурса, вы должны обращаться с ним как с массивом.

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

должно быть:

POST /users/{id}/assets    
{services:[{ attribute1:"var", attribute2:"var"}]}

Если вы собираетесь использовать этот способ

В-третьих: я не предпочитаю использовать этот способ для разработки проекта, если этот случай потерпел неудачу, как вы могли знать, что он потерпел неудачу при создании актива или услуги,

Вот другая линия мысли:

POST /relationships
{ relationship:${id}, asset:{id}, service:{id}, user:{id}, data:"some data" }

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

Затем вы можете получить конкретные отношения с помощью:

GET /relationships?id="2144321"

или искать подмножество отношений по:

GET /relationships?user="43434"

или

GET /relationships?asset="12433"

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