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

Question

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

#1 da (3 voti)
#2 da (2 voti)
#3 da (0 voti)

8

Attualmente stiamo progettando un'API REST per accedere ai dati dei clienti classici. Uno degli elementi nell'API è il patrimonio di un utente. Le risorse vengono aggiunte sotto un determinato servizio. L'API di backend aggiungerà un asset a un utente solo in base a un determinato servizio. Quindi, non esiste una relazione Utente - Asset, ma un Utente - [Servizio] - Relazione sull'assetto.

I nostri URI avranno questo aspetto:

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

Gli usi dell'API conosceranno l'ID risorsa e l'ID servizio per creare una nuova voce. Ciò a cui stiamo combattendo è la creazione di questa relazione.

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

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

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

In alternativa, stiamo considerando POST'ing all'URI che indirizza la relazione, in questo modo:

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

Ma in questo caso, il percorso della risorsa /users/{id}/assets/{id} non esiste prima del POST e verrà creato come un effetto collaterale.

L'invio POST a un percorso di risorsa che non esiste ancora consentito a tutti?

Grazie per i tuoi pensieri,

Gerard.

design design-patterns rest

posta maasg 29.04.2013 - 14:09

fonte

3 risposte

Leggi altre domande sui tag design design-patterns rest

Come utilizzare BDD per testare un compilatore? Diagramma dei messaggi su un bus di servizio

score 3 · Answer 1

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 accesso all'accesso è uno schema di sviluppo valido e accettabile, la risposta è sì, è valida e un modello abbastanza comune da vedere.

score 2 · Answer 2

Ci sono più punti qui: Primo: Non dovresti inserire l'id quando crei una nuova risorsa poichè questo ID potrebbe già esistere, o potrebbe essere il sistema che usa una tecnica specifica per generare l'id e lo stai forzando a usare il tuo, e per la proposta di che l'id deve essere creato dal sistema l'attributo dell'intestazione dell'ubicazione deve essere impostato in caso di risorsa di creazione, per ottenere il feed con l'id generato.

Secondo: Il tuo JSON non è corretto, devi occuparti del servizio come un altro oggetto all'interno dell'oggetto asset anche come nel servizio dell'URI della risorsa "s" devi occupartene 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 intendi utilizzare in questo modo

Terzo: Non preferisco utilizzare in questo modo la proposta di design, in caso contrario, come potresti sapere che non è riuscito durante la creazione di asset o servizi,

score 0 · Answer 3

Ecco una linea di pensiero diversa:

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

In questo modo stai sfidando le relazioni come un collegamento a tre vie tra risorsa, servizio e utente e non implicando alcuna relazione gerarchica

Puoi quindi 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 più flessibilità su chi viene utilizzato.