Framework API REST. Comportamento consigliato per parametro querystring non valido

Question

Sto implementando un framework API REST e mi chiedo quale sia il comportamento consigliato, quando un client invia un parametro querystring non valido.

illustrerò quello che voglio dire con un esempio specifico: dire che ho un gestore API sul/api/contatti/endpoint, e il gestore fornisce un filtro querystring chiamato id, che consente ai clienti di selezionare determinati contatti con gli ID forniti.

Quindi, una richiesta GET o DELETE potrebbe essere /api/contacts/?id=2&id=4&id=lalalala.

Chiaramente, non esiste un contatto con id=lalalala. In questo caso, come dovrebbe comportarsi il server?

• Ignorare l'valida contatto con id=lalalala, e filtrare solo i contatti sulle ID validi, 2 e 4.

• rispondere con un codice di errore che indica questo errore. Se sì, quale codice di errore dovrebbe essere fornito?

Grazie in anticipo.

Modifica: Per chiarire; L'obiettivo principale del framework che sviluppo, è quello di avere un comportamento prevedibile e quindi codici di risposta. Per questo motivo, voglio che i client utilizzino un'API costruita su questo framework, per aspettarsi le sorprese meno possibili. Quindi, la domanda è fondamentalmente: l'API dovrebbe restituire un errore in questo caso (e se sì, quale)? Oppure ignora le voci di filtro non valide e filtra solo i parametri querystring corretti?

Answer 1

In seguito alla lettera della legge, la risposta dovrebbe essere una 404 Non trovata. Tuttavia, nessuno si arrabbierà troppo con te se preferisci restituire 400 - cattiva richiesta.

Tuttavia, restituirei sicuramente un codice di stato 4XX. Vuoi che il cliente sappia che hanno fatto un errore.

Answer 2

Poiché si tratta di una chiamata REST, stiamo parlando di risorse. E ogni volta che abbiamo un filtro sbagliato, dovremmo restituire un codice di errore corretto.

In questo caso vorrei andare per 400 - bad request come la risorsa è stata trovata e mappata correttamente (/api/contacts), ma c'era un problema con la parte query string. Pertanto uno 400 e non uno 404.

Restituisce un 404 se qualcuno ha richiesto /api/contacts-all o qualche risorsa inesistente.

EDIT sulla base dei commenti qui sotto

Accetto al tuo commento. Idealmente un 400 è un problema con la richiesta. Passando da quello, è possibile utilizzare uno 422 Unprocessable Entity. Si prega di guardare il link StackOverflow qui sotto e parla della stessa cosa.

direi che gli sviluppatori di tutto il mondo sarebbe più comodo vedere un 400 di 422 per tali errori logici a causa del fatto che le aziende più grandi stanno usando 400 e non 422.

Riferimenti: Http status codes e 400 for logical error vs malformed request