API Web: evitare conflitti di nomi nei parametri di query URL

2

Sto implementando un'API simile a REST e ho appena affrontato un problema interessante. È necessario fornire una risorsa con un elenco aperto di parametri di query per filtrare i risultati. Ad esempio:

GET /api/items?field1=value1&field2=value2

I nomi dei campi sono configurabili, quindi non ho la lista completa dei possibili nomi.

Ci sono anche parametri con un significato speciale, ad es. orderBy=field5

Il problema è quando c'è un campo con lo stesso nome di uno dei parametri predefiniti. L'API deve in qualche modo distinguere tra loro.

Molti programmi a riga di comando utilizzano due trattini ("-") per contrassegnare la fine delle opzioni e l'inizio degli argomenti. Penso a qualcosa di analogo negli URL.

C'è qualche buona pratica in questo argomento?

    
posta pkalinow 13.02.2015 - 09:51
fonte

2 risposte

2

Una soluzione semplice consiste nell'aggiungere un prefisso a tutti i campi della query (o almeno a quelli personalizzati). Nel mio caso i campi possono essere in classi diverse, ad es. "core" o "personalizzato" quindi è conveniente usare prefissi per differenziarli. Ad esempio, "core.field1", "custom.field10". Come effetto collaterale, risolverà il problema con i conflitti. Se qualcuno aggiunge un campo chiamato orderBy, sarà comunque in grado di essere utilizzato per filtrare senza alcun conflitto con il parametro speciale con lo stesso nome:

custom.orderBy=something&orderBy=field1
    
risposta data 20.02.2015 - 15:34
fonte
1

Puoi anche mescolare i campi speciali con i nomi dei campi. per es.

/api/items?field1.orderByDesc=value1&field2=value2&field3.orderByAsc=value3

Con questo approccio, tieni i filtri specifici del campo vicino al campo senza dover scansionare il valore di un parametro separato. Ovviamente se si dispone di alcuni parametri speciali non correlati al campo, come le richieste di impaginazione, allora il parametro speciale "filtri" è la soluzione migliore. Puoi renderlo meno incline ai conflitti prefiggendo una sequenza di caratteri improbabile come

/api/items?field1.orderByDesc=value1&field2=value2&field3.orderByAsc=value3&z9x8y7rowStart=100&z9x8y7count=50

L'approccio z9x8y7 è simile al modo in cui PHP prefigura un nome di variabile prima di $.

Su una nota diversa, potresti voler aggiungere un numero di versione nell'API stessa, ad esempio

/api/v1/items?........

Ciò ti consentirà di mantenere attive più versioni della tua API, dando così ai tuoi utenti il tempo di convertirsi a una nuova versione della tua API quando rilascerai una nuova API. Alcuni esempi: link

    
risposta data 18.02.2015 - 06:36
fonte

Leggi altre domande sui tag