Progettazione di un'API REST con relazioni di risorse?

Question

Progettazione di un'API REST con relazioni di risorse?

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

1

Sto lavorando per progettare un'API REST da consumare da un React SPA.

Il lato client dello SPA richiede dati su una relazione tra due entità: Team e Player dove Teams ha molti Player s e Player s può appartenere solo a un Team .

Voglio interrogare tutti Team s e poi ottenere tutti i Player s per ogni squadra (che potresti immaginare sarebbe un tipico caso d'uso per queste risorse in una SPA.)

Riesco a vedere 3 approcci principali :

Espandi l'endpoint /teams con alcuni parametri ?expand=player o qualcosa di simile che include un array giocatore per ogni squadra . I dati tornano utili per essere utilizzati dall'applicazione di reazione, ma ora l'endpoint dell'API REST sta diventando più complesso e meno conforme al principio della responsabilità singola.
Query /teams per ottenere gli ID di tutti i team e quindi interrogare ogni squadra /team/:id/players . Ma questo aumenterà il numero di richieste al back-end, anche se separerà le responsabilità più e renderà le cose più esplicite.
Query /teams per ottenere gli ID di tutti i team e quindi eseguire query /players/:ids dove :ids è l'ID di tutti i team . Anche questo è abbastanza esplicito, ma potrebbe comportare un enorme URL e non è bello e ordinato.

Quale approccio è generalmente considerato il migliore? Ovviamente tutti hanno dei compromessi, ma forse sto trascurando alcuni trade-off?

api-design api rest single-responsibility web-api

posta Adam Thompson 26.08.2018 - 20:08

fonte

3 risposte

Leggi altre domande sui tag api-design api rest single-responsibility web-api

Esiste un diagramma per i test unitari? Componente e approccio di comunicazione esterni - REST o RPC?

score 2 · Answer 1

I want to query all the Teams and then get all the Players for each team

Come lo faresti come un sito web?

Se non stavi cercando di creare una "API REST", probabilmente dovresti creare una singola pagina html con tutti i dati che desideri; un recupero dal client, e tada, hai finito.

Se c'erano molti dati, potresti consegnarli come pagine multiple, collegate tra loro.

Ma in entrambi i casi, sarebbe solo un grosso blocco di HTML, che i client potrebbero tirare giù ottenendo il link.

L'ortografia del link è importante? Non per il cliente, lo stanno solo recuperando. Il server deve essere in grado di associare il codice HTML corretto al collegamento, ma il server può farlo in qualsiasi modo.

Quindi, se vuoi mettere quella pagina nella tua /teams gerarchia, o nella tua /players gerarchia, o in una% completamente separata/league, /reports o /views gerarchia, queste sono tutte scelte perfette .

Il fatto che la rappresentazione che stai usando sia un documento JSON, piuttosto che HTML, o XML, o qualsiasi altra cosa, non lo cambia.

Parte del punto di REST è che non è importante che il client sia in grado di disassemblare l'URI e dedurre lo schema del database.

Ciò che il server sta effettivamente facendo per trovare la rappresentazione corretta è un dettaglio di implementazione che nascondiamo dietro l'interfaccia uniforme.

score 1 · Answer 2

Dipende dalle funzioni dei client dell'applicazione, dalla quantità di dati e dalle prestazioni delle richieste di elaborazione.

Se tutti i giocatori di tutti i team sono sempre richiesti, includere la raccolta di Giocatori in ogni risorsa Team che viene restituita.

Se i dettagli dei giocatori non sono sempre richiesti, ogni squadra può includere la raccolta di tutti gli ID giocatore e recuperare i dettagli secondo necessità.

Se i giocatori non sono richiesti per tutte le funzioni dell'applicazione in cui vengono processate le squadre, procurati i giocatori se necessario.

Ma l'URL non è davvero importante. Per un'API REST è più importante definire in che modo i client scoprono quali URL esistono per eseguire azioni sulle risorse, a seconda del loro tipo MIME. Questa è la HATEOAS (Hypermedia As The Engine Of Application State) parte di REST.

score 0 · Answer 3

Penso che l'opzione n. 2 sia la più semplice da comprendere, implementare e mantenere, perché è possibile crearla in base ad alcune operazioni CRUD di base, che potrebbero anche essere riusabili in altri casi.

Risulterà in più richieste al tuo server, ma probabilmente puoi gestirle in modo asincrono e in parallelo, quindi l'applicazione sarà ancora reattiva.

Se il tuo back-end ha un buon ridimensionamento orizzontale, avere richieste più piccole potrebbe effettivamente offrirti prestazioni migliori.