Modellazione delle relazioni delle risorse con API RESTful

Question

Quando si progetta un'API RESTful le risorse che dipendono da altre devono essere modellate come sub-uris o devono semplicemente fare riferimento l'una all'altra?

E.g. presumendo una porta è sempre dipendente da una casa allora

/house/73/door/1 

o

/house/73 
/door/1044 

dove casa e la porta includono riferimenti a vicenda?

La maggior parte delle API RESTful che ho trovato sono piuttosto piatte, quindi valuterò i riferimenti a tutti quelli che hanno dipendenze di relazione più complesse.

saluti

Answer 1

In termini UML, se la relazione è quella di Aggregazione, si utilizza una gerarchia piatta con collegamenti tra le cose, mentre se la relazione è quella di Composizione (ovvero, la durata di un door è strettamente limitata dalla durata di vita di a house) si utilizzano risorse secondarie.

Non sto suggerendo di disegnare un diagramma UML! Ma aiuta a tenere a mente questa distinzione. (Si potrebbe anche modellare il caso Aggregation avendo risorse secondarie che sono semplicemente reindirizzate a quelle reali, i reindirizzamenti sono RESTful. OTOH, in realtà non mi piace farlo, preferisco rendere esplicite le relazioni e mantenere numero di reindirizzamenti verso il basso.)

Answer 2

Basta ricordare che URI sono un dettaglio di implementazione del server. Se puoi modellarli come risorse piatte, fallo. Sarà più facile per il server gestirli.

Se l'identificativo per la porta non è univoco in tutte le case, allora il server avrà bisogno di conoscere la casa e quindi è necessario includere la casa nell'URI.

Le relazioni tra le risorse devono essere modellate mediante collegamenti all'interno delle rappresentazioni restituite. La rappresentazione della tua casa dovrebbe probabilmente contenere collegamenti a tutte le risorse della porta di quella casa. Ti consigliamo di provare a evitare di utilizzare la struttura dell'URL con un significato di dominio.

Utilizzare solo una gerarchia se è necessario per identificare in modo univoco la risorsa.