Mi chiedo come gestire i risultati vuoti restituiti dalle query di ricerca in un servizio web REST:
C'era una query come mia_ressource_collection / {id} e la risorsa non esisteva restituirei 404 - Non trovato
Ma, se il mio URI è più simile a una query di ricerca come: my_ressource_collection /? fromDate = {fromDate} & toDate = {toDate} & filter1 = {filter1} & page = {page}: Fa la stessa logica si applica? Se nessun risultato corrisponde ai perametters, devo restituire uno stato 404?
Penso che nella maggior parte dei casi la reazione più utile sarebbe quella di restituire una risposta regolare (HTTP 200) e inviare dati vuoti. Ad esempio, se stai restituendo JSON potresti inviare
{}
Un'altra buona opzione potrebbe essere il codice HTTP "204 - Nessun contenuto".
I codici 4xx descrivono un errore del client, quindi il codice 404 non sarebbe una buona idea, perché è una richiesta valida, anche se non ci sono dati corrispondenti.
I codici di stato HTTP sono specifici per il protocollo HTTP. Quindi, se la richiesta ha esito positivo, nel senso che nulla è andato storto con la negoziazione HTTP, è necessario restituire lo stato HTTP 200 OK.
Il fatto che il numero di righe di risultati in una query completata correttamente sia zero è completamente irrilevante per il protocollo che si utilizza per la comunicazione.
Quindi, non mescolare i due: restituire una risposta riuscita valida, portando un set di risultati vuoto.
In effetti, a mio parere, anche se l'esecuzione della tua query ha provocato un errore come "tabella o vista sconosciuta", dovresti ancora non mescolare i codici di errore specifici per la tua applicazione con i codici di errore HTTP. Per quanto riguarda HTTP, c'era una richiesta HTTP perfettamente valida, che ora sta ricevendo una risposta HTTP perfettamente valida, e qualsiasi informazione su ciò che l'applicazione ha fatto mentre serviva la richiesta, come i risultati o perché i risultati non potevano essere ottenuto, deve essere incluso nel payload specifico dell'applicazione della risposta e non è uno degli affari di HTTP.
No, la stessa logica non si applica.
204 è il maggior risultato per questo scenario.
Vedi, il 4xx implicito significa che qualcuno "incasinato" in qualche modo. O l'utente ha inserito alcune informazioni non valide o l'implementatore dell'interfaccia non ha utilizzato correttamente l'API Rest, comunque la richiesta ha bisogno di un "ritocco" ... Nel primo esempio, l'utente ha inserito un'informazione non valida (il id ) , ma nel secondo, fintanto che ha inserito una data valida e così via, non sono stati commessi errori, quindi la richiesta è stata compresa e completata senza errori.
200 con un JSON vuoto non è l'approccio migliore perché potrebbe indurre gli utenti dell'API a credere che si sia verificato un errore o qualcosa del genere.
O un 204 NoContent o un 200 OK andrebbe bene fintanto che viene comunicato al consumatore in qualche modo.
Una query che restituisce un set di risultati vuoto non è rara nella programmazione e quindi non dovrebbe essere strana neanche a livello di API.
Personalmente Dipende dal tipo di query che viene eseguita nella mia API. Una query standard che in genere restituisce più righe di dati se i parametri corrispondono, potrebbe farmi inclinare verso un 200 OK con un risultato vuoto che corrisponde al normale comportamento della query.
Ex in JSON:
{
'results' : [
]
}
Tuttavia, se la query stessa doveva essere un componente di posizione, pensare a un problema di routing complicato, quindi restituire un 204 NoContent o anche un 404 non trovato a seconda della gravità, in modo che il consumatore possa riconoscere il problema e prendere azioni aggiuntive.
Leggi altre domande sui tag api-design rest web-services