Tworzenie relacji encji w REST: Czy mogę utworzyć element nadrzędny, publikując w identyfikatorze podrzędnym?

Obecnie projektujemy interfejs API REST w celu uzyskania dostępu do klasycznych danych klientów. Jednym z elementów interfejsu API są zasoby użytkownika. Aktywa są dodawane w ramach danej usługi. Interfejs API zaplecza doda zasób tylko do użytkownika w ramach danej usługi. Zatem nie ma relacji użytkownik - zasób, ale relacja użytkownik - [usługa] - zasób.

Nasze URI będą wyglądać następująco:

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

Zastosowania interfejsu API będą znały identyfikator zasobu i identyfikator usługi do utworzenia nowego wpisu. Zmagamy się z tworzeniem tej relacji.

Jednym prostym sposobem byłoby opublikowanie całej relacji /users/{id}/assets/

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

ale w rzeczywistości nie tworzymy zasobu, jak może wskazywać identyfikator URI, ale relację między zasobami a usługą.

Alternatywnie rozważamy wysyłanie testu POST do identyfikatora URI adresującego relację, w następujący sposób:

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

Ale w tym przypadku ścieżka zasobów /users/{id}/assets/{id}nie będzie istniała przed testem POST i zostanie utworzona jako efekt uboczny.

Czy przesyłanie POST do ścieżki zasobów, która jeszcze nie istnieje, jest w ogóle dozwolone?

Dzięki za twoje myśli

Gerard

Wygląda na to, że sugerujesz, że za każdym razem, gdy użytkownik po raz pierwszy opublikuje nieistniejącą relację, utworzysz ją jako część wpisu.

Jeśli zastanawiasz się, czy tego rodzaju wzorzec tworzenia podczas uzyskiwania dostępu jest prawidłowym, akceptowalnym wzorcem programistycznym, odpowiedź brzmi tak - jest zarówno prawidłowy, jak i dość powszechny.

Istnieje wiele punktów: Po pierwsze: nie należy umieszczać identyfikatora podczas tworzenia nowego zasobu, ponieważ ten identyfikator może już istnieć, lub może to być system wykorzystujący określoną technikę do generowania identyfikatora, a ty zmuszasz go do używania swojego identyfikatora i dla sugerują, że identyfikator musi zostać utworzony przez system, atrybut nagłówka lokalizacji musi być ustawiony w przypadku zasobu tworzenia, aby uzyskać feed z wygenerowanym identyfikatorem.

Po drugie: Twój JSON jest niepoprawny, musisz zająć się usługą jako innym obiektem wewnątrz obiektu zasobu, ponieważ w usłudze URI zasobów musisz poradzić sobie z nią jako tablicą.

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

musi być:

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

Jeśli zamierzasz używać w ten sposób

Po trzecie: nie wolę używać tej metody do zaproponowania projektu, jeśli ten przypadek się nie powiedzie, skąd możesz wiedzieć, że nie powiódł się podczas tworzenia zasobu lub usługi,

Oto inna myśl:

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

W ten sposób definiujesz relacje jako potrójny łącznik między zasobem, usługą i użytkownikiem, nie sugerując żadnych relacji hierarchicznych

Następnie możesz odzyskać określoną relację poprzez:

GET /relationships?id="2144321"

lub wyszukaj podzbiór relacji według:

GET /relationships?user="43434"

lub

GET /relationships?asset="12433"

Pierwotny sposób nie jest zły, ale takie podejście może dać ci większą elastyczność w zakresie tego, kto się przyzwyczai.