Quando utilizzare le risorse nidificate in un'API RESTful

No, non c'è niente di sbagliato nell'avere più risorse per la stessa "cosa", in questo caso elenchi di collegamenti.

Recentemente abbiamo avuto problemi con lo stesso problema. La nostra decisione era quella di avere tutte le risorse dove non c'è una proprietà strict da non annidare. In altre parole, i collegamenti sarebbero modellati sotto

/links -- all links
/links/:linkid -- a particular link

Quindi, i filtri sulla raccolta dei collegamenti sono espressi come parametri di query. Quindi, per ottenere i collegamenti di un determinato utente, useresti:

/links?user=/users/:userid

Ciò consente anche una più facile composizione dei filtri:

/links?user=/users/10&since=2013-01-01

Ed è facile da capire concettualmente - hai una collezione di elementi e aggiungi filtri ad essa.

Detto questo, non c'è niente di più "RESTful" su questo approccio rispetto a qualsiasi altro schema di denominazione URI. È solo una convenzione che abbiamo trovato leggibile dagli umani e facile per noi sviluppatori capire e abbracciare. REST non si preoccupa di ciò che hai inserito negli identificatori delle risorse.

Quindi la mia preoccupazione è: / users /: userid / links restituisce "links", MA se user_id non è identificato, questo dovrebbe restituire un 404.

Tuttavia

/ links? userid =: userid potrebbe potenzialmente restituire una lista vuota (essenzialmente una 200) che in realtà è probabilmente un bug. E abbastanza possibile.

Sebbene funzionino entrambi, il raggruppamento offre funzionalità aggiuntive che puoi disegnare in seguito.