Come dovrebbe una API Web gestire i parametri errati / extra?

Naviga le tue risposte
8

Domanda: per un'API web pubblica (invia richieste HTTP Get / Post, ottieni dati JSON / XML), come devono essere gestiti i parametri errati o extra.

Mi sembra che se i parametri errati vengono ignorati, un errore nel codice del chiamante può passare inosservato poiché restituirebbe un risultato valido. Questo può essere particolarmente vero in situazioni in cui non sarebbe ovvio guardando i risultati restituiti.

Mi riferisco solo ai parametri opzionali. Ovviamente se un parametro richiesto è errato, il parametro verrà considerato mancante e verrà restituito un errore.


Come esempio , la Ricerca Place La chiamata API ha quattro parametri obbligatori (posizione, raggio, sensore e chiave) e diversi parametri facoltativi (i tipi è uno di questi).

Posso eseguire questi comandi (con una chiave API) e ottenere risultati validi: 

curl "https://maps.googleapis.com/maps/api/place/search/json?location=45.47554,-122.794189&radius=500&sensor=false&key=<api_key>&type=bakery"

curl "https://maps.googleapis.com/maps/api/place/search/json?location=45.47554,-122.794189&radius=500&sensor=false&key=<api_key>&types=bakery"

Il primo comando ha il parametro "types" nella forma singolare che è un nome di chiave non valido. L'API ignora quel parametro e restituisce tutti i tipi di entità. In questo caso, l'errore è ovvio, ma potrebbero esserci delle volte (e altre chiamate API) in cui non lo sarà.

    
posta juan2raid 08.08.2011 - 21:17
fonte

3 risposte

3

Ignorare parametri extra è una pratica standard. È facile scrivere un codice come questo 

if (params.type) { 
  ... 
}

Non vale la pena di controllare tutti i parametri passati per vedere se alcuni non sono validi. Gli errori ortografici sono il problema del cliente.

    
risposta data 08.08.2011 - 21:45
fonte
1

Se fosse un piccolo sforzo includere un test di ortografia per i nomi dei parametri (quanto lavoro vuoi fare, controllando i nomi di TUTTI i parametri rispetto a un elenco di errori di ortografia più probabili?), potrei farlo ma normalmente Ti consiglio di ignorare i parametri aggiuntivi errati. Certo, potrebbe essere bello se un WebService restituisca un messaggio "Nessun parametro valido type , intendevi types ?" ma solo se hai il tempo di implementarlo correttamente, e dal momento che di solito non mi aspetto che quel tipo di messaggio torni, non mi mancherà se non ci sarà.

    
risposta data 08.08.2011 - 21:33
fonte
1

Penso che dipenda da come viene specificata l'API e da chi è stato reso responsabile di questi problemi. Se dovessi progettare un'API, metterei la proprietà di assicurarmi che i parametri corretti previsti (e i relativi valori associati se presenti) fossero gestiti nel modo previsto o se ci fosse un input inaspettato (come richiesto per proteggere il metodo da strani e dati stravaganti) è stata lanciata l'eccezione appropriata o è stato restituito il codice di errore.

Direi quindi che tutti gli input che non fanno parte degli elenchi dei parametri previsti non fanno parte del problema dell'API. Ciò ti consente di essere specifico e di assumere la proprietà di una specifica ben definita e chiunque desideri utilizzarlo ha la responsabilità di assicurarne l'utilizzo appropriato.

Hai fornito uno strumento e una serie di istruzioni su come usarlo. Rendi la responsabilità dell'utente di usarlo correttamente.

    
risposta data 08.08.2011 - 21:50
fonte

Leggi altre domande sui tag

Principio di inversione delle dipendenze: Comprendere come sia le componenti di basso livello che i componenti di alto livello dipendono dalle astrazioni Qual è il modo migliore per monitorare le distribuzioni di applicazioni Web in analitica?