API REST, percorsi nidificati senza fornire identificatori a ogni livello annidato

Question

API REST, percorsi nidificati senza fornire identificatori a ogni livello annidato

#1 da (3 voti)

1

Ovviamente un'API RESTful potrebbe contenere percorsi di base come:

api/competitions
api/competitions/{id}
api/teams
api/teams/{id}
api/players
api/players/{id}

E percorsi nidificati come:

api/competitions/{id}/teams
api/competitions/{id}/teams/{id}/players
api/teams/{id}/players
...

Ma per quanto riguarda il seguente esempio ( Percorso A ):

api/competitions/{id}/teams/players

Quindi tutti i giocatori, per tutte le squadre che si trovano in una certa competizione?

Q1: questo contrasta la progettazione REST?

Q2: Presumibilmente lo fa, ma c'è qualche documentazione che lo afferma esplicitamente? Ho fatto qualche ricerca e non riesco a trovare nulla che lo escluda dal momento che gli esempi sono tutti molto semplicistici.

Potresti implementare ( Percorso B ):

api/competitions/{id}/players

invece, e quindi sotto la logica assicurerebbe che i giocatori non siano TUTTI i giocatori (come in api/players ) ma considerino la squadra e quindi la competizione - in modo che i giocatori che non hanno una squadra siano esclusi.

Tuttavia, passando da questo semplice esempio a un modello più astratto, potrebbero esserci degli scenari in cui Percorso B potrebbe essere più confuso per un utente API di Percorso A .

Q3: Ci sarebbe mai una giustificazione per l'implementazione di una route nidificata (come Route A ) senza tutti gli identificatori a tutti i livelli?

api-design api rest

posta Adam Marshall 20.03.2015 - 11:49

fonte

1 risposta

Leggi altre domande sui tag api-design api rest

Clojure NameSpace Design Il modo più efficace per salvare le immagini e inviarle al browser client

score 3 · Answer 1

No. REST non si preoccupa di come organizzi le tue risorse, solo che le singole risorse sono identificate dagli URL e che le risorse sono individuabili da altre risorse. Se api/competitions/{id}/teams/players ha senso per la tua applicazione, allora usalo, purché gli utenti possano trovare un link ad esso.
Tesi di Roy Fielding su Trasferimento dello stato di rappresentanza , in particolare sezioni < a href="https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1"> 5.2.1.1 Identificatori di risorse e risorse e 6.2 REST applicato all'URI . Cerca anche in HATEOAS (Hypertext come Engine of Application State).
Sì, se è compreso e comodo per gli utenti della tua applicazione.

REST è un concetto architettonico di alto livello. Non riguarda il modo in cui annidi i tuoi identificatori. Dipende da te e dai requisiti della tua applicazione. Fai ciò che ha senso ed essere ovvio a riguardo.