Modellazione di una risorsa che potrebbe non essere parte della risorsa genitore

Question

Modellazione di una risorsa che potrebbe non essere parte della risorsa genitore

#1 da (0 voti)

2

Sto progettando un'API e sto riscontrando un paio di problemi con alcune parti della modellazione delle risorse.

Ho la nozione di SurveyItem che come forma collettiva a Survey :

Survey Resource Endpoint:
http://api.somewhere.com/survey

Accessing Survey Items
http://api.somewhere.com/survey/1/surveyitems

Piuttosto basico e non sono eccessivamente preoccupato di quanto sopra. SurveyItems non può esistere al di fuori del contesto di un'indagine, quindi la gerarchia.

Dove sto lottando un po 'è il livello successivo. Un SurveyItem non è necessariamente una cosa (sopportare me) poiché si basa su un'interfaccia implementata ma potresti avere qualcosa come un "Sondaggio semplice" che ti consente di prendere appunti, un "Sondaggio video" ti consentirà di prendere un sondaggio tramite video ecc, quindi sono tutti parte integrante dell'implementazione di base ma potrebbero potenzialmente avere risorse secondarie diverse.

Image and note survey type sample endpoints
http://api.somewhere.com/survey/1/surveyitems/1/images
http://api.somewhere.com/survey/1/surveyitems/1/notes

Video Survey
http://api.somewhere.com/survey/1/surveyitems/2/videos
http://api.somewhere.com/survey/1/surveyitems/2/notes

Come puoi vedere sopra un SurveyItem può avere diversi endpoint secondari a seconda del tipo di SurveyItem che è. Stavo pensando di modellarlo come sopra ma usando un approccio HATEOAS per rispondere con un URL di raccolta degli endpoint secondari disponibili per ogni singolo tipo di sondaggio in modo che possano essere rilevati dai clienti.

È una cosa ragionevole da fare o ci sono approcci migliori per gestire cose come questa?

rest modeling

posta Roberto Modica 05.07.2013 - 20:31

fonte

1 risposta

Leggi altre domande sui tag rest modeling

Gestione della quantità dinamica di stringhe per la memorizzazione persistente e di runtime in un'app IOS È effettivamente possibile avere un linguaggio di programmazione 'utile' che non è completo Turing?

score 0 · Accepted Answer

Suoni perfettamente ragionevoli.

In un servizio basato su hypermedia, la forma dei tuoi URL non è molto importante.

Potresti anche avere una struttura piatta:

http://api.somewhere.com/survey/1
http://api.somewhere.com/surveyitems/1
http://api.somewhere.com/videos/1
http://api.somewhere.com/notes/1

O semplicemente usa gli ID globali:

http://api.somewhere.com/1 (a survey)
http://api.somewhere.com/2 (a video surveyitem for survey 1)
http://api.somewhere.com/3 (a video for surveyitem 2)
http://api.somewhere.com/4 (a note)

La gerarchia che hai proposto trasmette informazioni molto più utili sull'identità delle tue risorse e delle loro relazioni rispetto a una di queste altre opzioni.

Inoltre, sarà probabilmente più semplice da implementare perché tutti gli identificatori univoci nell'URL verranno mappati correttamente alle tabelle del database normalizzate.

Potresti assegnare a ciascun tipo di SurveyItem il proprio pattern URL:

http://api.somewhere.com/survey/1/videosurveyitems/1
http://api.somewhere.com/survey/1/imagesurveyitems/1

Ma ciò sembra implicare che tutti i sondaggi conterranno raccolte distinte di ogni tipo di elementi, che non sembrano vere dalla tua descrizione.

Se in futuro decidi (ad esempio) che i video siano effettivamente indipendenti dai sondaggi, puoi sempre cambiare idea modificando i tuoi link e / o impostando un reindirizzamento:

http://api.somewhere.com/survey/1/surveyitems/1/videos/1
= HTTP 303 See Other: http://api.somewhere.com/videos/1