Creazione di una relazione di entità in REST: posso creare il genitore pubblicando un ID figlio?

Attualmente stiamo progettando un'API REST per accedere ai dati dei clienti classici. Uno degli elementi nell'API sono le risorse di un utente. Le risorse vengono aggiunte in un determinato servizio. L'API di back-end aggiungerà una risorsa a un utente nell'ambito di un determinato servizio. Quindi, non esiste una relazione utente - risorsa, ma una relazione utente - [servizio] - risorsa.

I nostri URI saranno così:

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

Gli usi dell'API conosceranno l'id dell'asset e l'id del servizio per creare una nuova voce. Ciò con cui stiamo lottando è la creazione di questa relazione.

Un modo semplice sarebbe quello di pubblicare l'intera relazione /users/{id}/assets/

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

ma in realtà non stiamo creando un asset come potrebbe indicare l'URI, ma una relazione asset-service.

In alternativa, stiamo prendendo in considerazione il POST'URI indirizzando l'URI alla relazione, in questo modo:

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

Ma in questo caso, il percorso delle risorse /users/{id}/assets/{id}non esisterà prima del POST e verrà creato come effetto collaterale.

Il POST sta seguendo un percorso di risorse che non esiste ancora?

Grazie per i tuoi pensieri,

Gerard.

Sembra che tu stia suggerendo che, ogni volta che un utente pubblica per la prima volta una relazione inesistente, la creerai come parte del post.

Se ti stai chiedendo se questo tipo di modello di creazione all'accesso è un modello di sviluppo valido e accettabile, la risposta è sì, lo è - è entrambi validi e un modello abbastanza comune da vedere.

Ci sono più punti qui: Primo: Non si deve inserire l'id quando si crea una nuova risorsa poiché questo ID potrebbe essere già esistente o potrebbe essere il sistema che utilizza una tecnica specifica per generare l'id e lo si sta costringendo a utilizzare il proprio, e per il proponete che l'id debba essere creato dal sistema l'attributo header di posizione deve essere impostato in caso di risorsa di creazione, per ottenere il feed back con l'id generato.

Secondo: il tuo JSON non è corretto, devi trattare il servizio come un altro oggetto all'interno dell'oggetto asset anche come nel "s" del servizio URI della risorsa devi gestirlo come array.

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

deve essere:

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

Se hai intenzione di usare in questo modo

Terzo: non preferisco utilizzare questa modalità per la proposta di progettazione, se questo caso ha esito negativo, come è possibile sapere se si è verificato un errore durante la creazione di asset o servizi,

Ecco una diversa linea di pensiero:

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

In questo modo si stanno definendo le relazioni come un collegamento a tre vie tra risorsa, servizio e utente e non si intende alcuna relazione gerarchica

È quindi possibile recuperare una relazione specifica tramite:

GET /relationships?id="2144321"

o cerca un sottoinsieme di relazioni per:

GET /relationships?user="43434"

o

GET /relationships?asset="12433"

Il modo originale non è sbagliato, ma questo approccio può darti una maggiore flessibilità su chi viene utilizzato.