Come progettare endpoint API per pubblicare un oggetto figlio e ottenere tutti i figli di tutti i genitori?

5

Ad esempio, ho entità: Client, Report. Il cliente può avere molti report e penso che l'endpoint per una singola gestione di Report debba essere annidato in questo modo:

/clients/{client_id}/reports/{report_id}

Come per tutti i report di un client, l'enpoint è previsto:

/clients/{client_id}/reports

Ma come dovrebbe sembrare un endpoint per ottenere tutti i report di tutti i client per mantenere l'API coerente e ben progettata.

I miei approcci:

  1. (l'ho visto in alcuni google api) usa "-" al posto di esso e lo analizzo come "tutto":

/clients/-/reports

Questo mantiene il formato dell'endpoint allo stesso modo, ma sembra un po 'insolito, non riesce a trovare alcun rfc che suggerisca in questo modo.

  1. Crea un endpoint separato solo per tutti i rapporti:

/reports

Ma per ottenere i rapporti del cliente è ancora:

/clients/{client_id}/reports

  1. Endpoint di refactoring per rendere "client" non un genitore, ma solo un parametro di filtro:

/reports?client={client_id} - rapporti di un cliente

/reports - rapporti di tutti i client

In caso di aggiunta di un nuovo endpoint per la pubblicazione di un report per un client specifico, potrebbe sembrare brutto, perché sarà una richiesta POST con un parametro nell'URL.

Ci sono altri suggerimenti di idee?

    
posta Yann 24.08.2017 - 16:57
fonte

2 risposte

2

But how should look an endpoint for getting all the Reports of all the Clients to keep API consistent and well designed.

Prima di ogni altra cosa, ricorda che non ci sono regole d'oro per la modellazione delle API RESTful. Tutto ciò che abbiamo sono le migliori pratiche e le convenzioni. Detto questo, la risposta più probabile è, come sempre, scegliere quella che meglio soddisfa le tue esigenze e in questo caso quella che meglio esprime il tuo modello.

Quindi controlla le tre opzioni dall'espressività.

# 1 La notazione "-"

Questa è un'idea brillante. Ci permette di esprimere la condizione tutta la reports che appartiene a clients . Sta riducendo la "query" a un insieme specifico di rapporti (quelli situati all'interno del limite clients ).

Mantiene sempre la nozione di gerarchia (appartenenza), quindi se reports può essere trovato in posizioni diverse, questa notazione fa un grosso problema. Ad esempio:

  • Tutti i rapporti che appartengono ai clienti /clients/-/reports
  • Tutti i rapporti che appartengono ai dipartimenti /departments/-/reports
  • Tutti i rapporti che appartengono ai dipendenti /employees/-/reports

Tuttavia, per recuperare tutti i report disponibili nel sistema, mantenere la gerarchia non fornisce alcun vantaggio prezioso rispetto alla prossima opzione.

N. 2 URI diversi

Se non abbiamo bisogno di esprimere confini / contesti / gerarchia al momento di recuperare tutti i rapporti disponibili , questo approccio mi sembra più ragionevole.

Anche il nuovo URI ( /reports ) lascia aperta la possibilità di una gestione dei report . Tuttavia, non è necessario fornirgli un supporto REST completo se non lo riteniamo necessario. Ad esempio, hai dichiarato Make a separate endpoint just for all the reports . Va bene, devi solo implementare GET e forse alcuni filtri per le query e il gioco è fatto.

Tieni presente che potresti ancora eseguire questo /reports?client={client_id} . Avere URI diversi per la stessa risorsa va bene. Alcuni articoli che ho letto chiamerebbero questo solidità .

# 3 Ripristino della gerarchia

Ho la sensazione che questo approccio non soddisfi le tue aspettative. Inoltre, penso, ti porterà al punto di partenza.

Conclusioni

Si noti che # 1 e # 2 non si escludono a vicenda. Possiamo implementare entrambi. Data la situazione attuale e secondo le premesse dell'OP, implementerei solo # 2.

1: equivale a /clients/-/reports Suppongo

    
risposta data 24.08.2017 - 22:11
fonte
0

I modelli di progettazione dell'API di Google suggeriscono di utilizzare "-" in questo scenario.

GET /clients/-/reports

Fonte:

link

    
risposta data 24.08.2017 - 17:34
fonte

Leggi altre domande sui tag