REST api design che consente il recupero di attributi distinti non chiave per un tipo di entità

Question

REST api design che consente il recupero di attributi distinti non chiave per un tipo di entità

#1 da (6 voti)

1

Abbiamo una API REST sotto design, per recuperare un'entità, ad esempio persone, come segue

GET /endpoint/version/persons/

Ora possiamo ottenere persone che vivono in una città particolare, come segue:

GET /endpoint/version/persons/?city=input_city

Possiamo anche ottenere tutte le città in cui le persone sono come segue, questo fornisce l'identità della persona e la città, l'identificazione della persona è unica mentre la città può o non può ripetere:

GET /endpoint/version/persons/?fields=city

La domanda è: come si dovrebbe progettare il resto se si desidera ottenere l'elenco distinto delle città?

In altre parole, qualcosa come

GET /endpoint/version/persons/?distinct_fields=city&sort=city

o

GET /endpoint/version/persons/?group_by=city&sort=city&fields=city

In questa chiamata non siamo interessati alle persone di per sé ma all'elenco delle città distinte.

Quale design renderà piacevole lo sviluppatore?

rest

posta alok 08.07.2016 - 01:33

fonte

1 risposta

Leggi altre domande sui tag rest

riprendere un progetto in cui era stato interrotto [chiuso] Dovrei utilizzare IDisposable qui, per gestire correttamente la memoria?

score 6 · Accepted Answer

The question is how should the rest api be designed if we wish to obtain the distinct list of cities?

GET /cities

Cercare di fare una risorsa di Dio che restituisca tutte le risorse a seconda della stringa di query è una cattiva idea e infrange i principi REST.

Le stringhe di query dovrebbero filtrare la raccolta specifica di una risorsa (cioè trasformare tutte le persone in un sottoinsieme specifico di persone), non essere utilizzate per determinare quale risorsa si sta cercando di ottenere in primo luogo. Ogni risorsa dovrebbe avere un URL specifico. Una raccolta di persone che ha il proprio URL è ok, ma avere risorse di città e persone nello stesso URL è fonte di confusione e aggiunge complessità all'implementazione del client.

Non dovresti costruire il tuo schema URL attorno a un singolo caso d'uso possibile del cliente. Lascia che il cliente si preoccupi perché vuole una risorsa. Attendendo che il cliente ottenga Cities tramite People , stai costringendo i progettisti dei clienti a capire che sul tuo sistema è così che ottieni le città.

Un ultimo punto non correlato alla domanda ma comunque importante. L'utilizzo di stringhe di query per filtrare i dati restituiti (ovvero ?field=city ) è un odore di progettazione. La negoziazione del tipo di contenuto dovrebbe determinare come la risorsa guarda al client, se il client vuole la rappresentazione in un formato specifico dovrebbe dirlo al server tramite l'intestazione, non l'URL. La ragione di ciò è di nuovo non aggiungere complessità a livello aziendale allo schema URL.