Che cos'è un codice di stato di risposta corretto a POST quando non viene trovata la risorsa padre?

Ho il seguente endpoint:

a/{id}/b

e vuoi crearne una bcon l'invio di una POSTrichiesta. Se acon dato {id}non viene trovato dovrei rispondere con 404 NOT_FOUNDo forse con 409 CONFLICT?

È per gestire la semplicità a/{id}, il trucco è che qui viene utilizzata una sottoresource.

— Opale
fonte

Possibile duplicato di Come gestire le regole aziendali con un'API REST?

— moscerino del

Risposte:

404 NOT FOUNDsembra la risposta appropriata, perché la risorsa con questo ID non esiste. È molto chiaro da capire e ti aspetti la stessa risposta se a/{id}viene chiamato.

409 CONFLICTnon mi sembra la scelta migliore, perché nel tuo esempio restituirai un 409 quando la risorsa padre non è stata trovata :).

Ma ricorda che la cosa più importante è la coerenza nella tua API

— Dherik
fonte

Sono d'accordo. Se dovessi provare a scrivere in una cartella che non esisteva, è un conflitto o un errore della cartella mancante? Mi sembra più intuitivo in questo modo.

— Neil

Una "cartella" intendi un percorso che non esiste?

— Dherik,

Intendo una cartella, come nel file system.

— Neil,

Puoi dettagliare lo scenario? Perché dipende. Se la cartella era prevista per il server e (per qualsiasi motivo) non ci fosse, penso che questo sia un errore del server (5xx) non un errore client (4xx). Se il valore di questa cartella è stato passato dal client alla risorsa (come il id), è 404. Ma se la cartella è stata passata nel corpo questo potrebbe essere qualcos'altro (412, 422 ... qualcosa da rappresentare "convalida fallita: la cartella non non esiste"). È una buona domanda da porre e discutere.

— Dherik,

Se chiedi al server il file con percorso /nonexistent/help.html e la cartella / inesistente non esiste, c'è solo una chiara risposta a questo. 404 file non trovato! Potrebbe esistere persino un /home/help.html e la risposta non sarebbe diversa. Questa è un'applicazione REST chiaramente, ma non vedo alcun motivo per cui la logica cambierebbe. Il genitore deve esistere per primo.

— Neil,

Oltre alla risposta di @ Dherik.

Gli URI sono identificatori , quindi dobbiamo tenerlo presente ( /a/{id}/bè un identificatore). L' URI non ha significato per il WWW, così come per il client HTTP.

404 è la risposta giusta . In sostanza, il server sta rispondendo

Non ho trovato alcuna risorsa con tale ID. Risorsa non trovata ¹

Non importa se la risorsa mancante è genitore o figlio .

Noi sviluppatori sviluppiamo gerarchie e percorsi nell'URI, ma i client HTTP no. In altre parole, HTTP deve essere interpretato solo dai client HTTP ma non dagli umani (sviluppatori, utenti finali, ecc.).

In caso di dubbi, non chiedere quale codice abbia senso per te (umano). Chiedi, quale codice ha senso per il client HTTP. Come vuoi che si comporti il client HTTP?

Perché? Poiché un codice di stato causa questi client per eseguire determinate operazioni. Ad esempio, 302 . Questo codice di solito consente ai browser Web di reindirizzare verso una posizione specifica (URI) informata nelle intestazioni di risposta.

Questo potrebbe non essere il tuo caso, ma è importante essere consapevoli. In definitiva, i codici di stato HTTP sono indirizzati ai client HTTP. Non per le nostre applicazioni. Non alle persone.

^{1: 409 viene implementato raramente come errore di navigazione. Di solito comporta l'esecuzione di operazioni remote (eliminazione, aggiornamento, nuovo, ecc.). Ma l'URI dovrebbe esistere. Altrimenti, prevarrà 404}

— LAIV
fonte