Створення взаємовідносин із сутністю в REST: Чи можу я створити батьківську адресу, розмістивши ідентифікатор дитини?

Зараз ми розробляємо API REST для доступу до класичних даних клієнтів. Одним із елементів в 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 переходить на ресурсний шлях, який ще не існує взагалі?

Дякуємо за ваші думки,

Джерард.

Здається, ви пропонуєте, що коли користувач вперше публікує повідомлення про неіснуюче відношення, ви створюватимете його як частину публікації.

Якщо ви запитуєте, чи такий тип шаблону створення-доступу є допустимим, прийнятним шаблоном розвитку, відповідь "так" - це є дійсним, і досить поширеним шаблоном.

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

По-друге: Ваш JSON невірний, ви повинні мати справу з сервісом як іншим об'єктом активу об'єкта, також як в службі URI ресурсу "s", ви повинні мати справу з ним як масив.

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"

Оригінальний спосіб не є помилковим, але такий підхід може дати вам більше гнучкості щодо того, до кого він звикає.