Perché includere gli ID delle risorse padre nell'endpoint REST?

Question

Perché includere gli ID delle risorse padre nell'endpoint REST?

#1 da (9 voti)
#2 da (6 voti)

7

Dire che ho un'applicazione di directory aziendale, quindi Companies ha Employees . Per me è abbastanza chiaro perché avresti i seguenti GET endpoint:

api/companies                # Get all company records
api/companies/{id}           # Get company with specified id
api/companies/{id}/employees # Get all employees for the company with specified id

Ma dimmi che voglio ottenere un record specifico per i dipendenti. Sembra che lo schema comune sia quello di fornire una risorsa:

api/companies/{id}/employees/{id}

Ma supponendo che un record employee sia posseduto solo da un company , perché dovresti fornire l'id di company in quell'URI? Non è semplicemente un parametro ridondante? Anche se è necessario acquisire il company per qualche tipo di logica dietro le quinte, puoi farlo abbastanza facilmente controllando semplicemente il genitore di employee . Quindi il mio istinto dice di fare l'endpoint in questo modo:

api/companies/employees/{id}

Eppure il precedente schema è così pervasivo, mi sento come se mi mancasse qualcosa. Qualcuno si preoccuperebbe di spiegare?

rest uri

posta aparkins 30.06.2016 - 17:02

fonte

2 risposte

9

Il problema con il supporto di GET /companies/{id}/employees/{id} e GET /companies/employees/{id} è che il significato del segmento di percorso dopo /companies è sovraccarico. Rappresenterebbe "una società specifica" o "una proprietà condivisa da tutte le società". È fastidioso implementare da parte tua, confondere i clienti, e ora devi tenere traccia del fatto che hai rimosso i "dipendenti" come possibili identificativi aziendali.

Se non ci sono proprietà di un dipendente che differiscono tra le aziende, basta fare:

GET /companies/{id}
GET /employees/{id}

Puoi anche supportare GET /employees?company={id} , GET /companies/{id}/employees , o entrambi, ma tutti i link self per i dipendenti devono puntare alla loro posizione canonica ( /employees/{id} ).

I tuoi ID per dipendenti e aziende dovrebbero quasi certamente essere generati dal tuo sistema e non correlati a dati specifici dell'utente, perché possono cambiare.

risposta data 30.06.2016 - 17:31

fonte

Leggi altre domande sui tag rest uri

Quale sarebbe un buon approccio per generare un albero di cartelle? Software aziendale: dove dovrebbe andare il codice? [duplicare]

score 6 · Accepted Answer

Non è garantito che gli ID dei dipendenti siano univoci tra le aziende.

In altre parole, potremmo imbattersi in questo scenario:

> GET api/companies/4711/employees/42
Smith, Winston

> GET api/companies/815/employees/42
O'Brien, Seamus

Se avessimo davvero il caso in cui gli ID dei dipendenti sono una risorsa indipendente dalle aziende (come SSN negli Stati Uniti ), quindi api/employees/{id} sarebbe molto meglio.