Quale codice di risposta dello stato HTTP dovrei usare se nella richiesta manca un parametro richiesto?

Sto pensando 412 (precondizione fallita) ma potrebbe esserci uno standard migliore?

Lo stato 422 sembra più appropriato in base alle specifiche .

Il codice di stato 422 (entità non elaborabile) indica che il server comprende il tipo di contenuto dell'entità richiesta (quindi un codice di stato 415 (tipo di supporto non supportato) è inappropriato) e la sintassi dell'entità richiesta è corretta (quindi un 400 (richiesta non valida) ) il codice di stato non è appropriato) ma non è stato in grado di elaborare le istruzioni contenute. Ad esempio, questa condizione di errore può verificarsi se un corpo di richiesta XML contiene istruzioni XML ben formate (cioè sintatticamente corrette), ma semanticamente errate.

Dichiarano che xml non valido è un esempio di sintassi errata (che richiede un 400). Una stringa di query non valida sembra analoga a questa, quindi 400 non sembra appropriato per una stringa di query ben formata a cui manca un parametro.

UPDATE @DavidV sottolinea correttamente che questa specifica è per WebDAV, non per HTTP di base. Ma alcune API non WebDAV popolari usano comunque 422, per mancanza di un codice di stato migliore ( vedi questo ).

Non sono sicuro che ci sia uno standard stabilito, ma avrei usato 400 Bad Request , che l'ultima specifica HTTP (dal 2014) documenta come segue :

6.5.1. 400 Richiesta non valida

Il codice di stato 400 (Richiesta non valida) indica che il server non può o non elabora la richiesta a causa di qualcosa che viene percepito come un errore client (ad es. Sintassi della richiesta non valida, framing del messaggio di richiesta non valido o instradamento della richiesta ingannevole).

L' API WCF in .NET gestisce i parametri mancanti restituendo un HTTP 404errore "Endpoint non trovato" quando si utilizza webHttpBinding .

Il 404 Not Foundgrado di dare un senso se si considera il servizio di web nome del metodo con la sua firma parametro. Cioè, se si espone un metodo di servizio Web LoginUser(string, string)e si richiede LoginUser(string), quest'ultimo non viene trovato.

Fondamentalmente ciò significherebbe che non è possibile trovare il metodo del servizio Web che si sta chiamando, insieme alla firma del parametro specificata.

10.4.5 404 non trovato

Il server non ha trovato nulla corrispondente all'URI di richiesta. Non viene fornita alcuna indicazione se la condizione è temporanea o permanente.

Il 400 Bad Request, come suggerito Gert , rimane un codice di risposta valida, ma penso che è normalmente usato per indicare i problemi di livello inferiore. Potrebbe essere facilmente interpretato come una richiesta HTTP non valida, forse intestazioni HTTP mancanti o non valide o simili.

10.4.1 400 Richiesta non valida

La richiesta non è stata compresa dal server a causa di una sintassi non corretta. Il client NON DOVREBBE ripetere la richiesta senza modifiche.

È possibile inviare un codice 400 Bad Request. È uno dei codici di stato 4xx più generici, quindi puoi usarlo per indicare ciò che intendi: il client sta inviando una richiesta in cui mancano informazioni / parametri richiesti dall'applicazione per elaborarlo correttamente.

In uno dei nostri progetti API decidiamo di impostare uno stato 409 su qualche richiesta, quando non possiamo riempirlo completamente al 100% a causa del parametro mancante.

Il codice di stato HTTP "409 Conflict" è stato per noi un buon tentativo perché la sua definizione richiede di includere informazioni sufficienti affinché l'utente possa riconoscere l'origine del conflitto.

Riferimento: w3.org/Protocols/

Quindi, tra le altre risposte come 400 o 404, abbiamo scelto 409 per imporre la necessità di esaminare alcune note nella richiesta utile per impostare una nuova e giusta richiesta.

In ogni caso, il nostro caso è stato particolare perché abbiamo bisogno di inviare alcuni dati se la richiesta non era completamente corretta, e dobbiamo imporre al cliente di guardare il messaggio e capire cosa non andava nella richiesta.

In generale se abbiamo solo qualche parametro mancante andiamo per un 400 e un array di parametri mancanti. Ma quando abbiamo bisogno di inviare qualche informazione in più, come un caso particolare e vogliamo essere più sicuri che il cliente se ne occuperà, inviamo un 409

Di solito vado per 422 (entità non elaborabile) se qualcosa nei parametri richiesti non corrispondesse a quello richiesto dall'endpoint API (come una password troppo breve) ma per un parametro mancante andrei per 406 (inaccettabile).

Per gli interessati, Spring MVC (almeno 3.x) restituisce un 400 in questo caso, il che mi sembra sbagliato.

Ho testato diversi URL di Google (account.google.com) e rimosso i parametri richiesti e in genere restituiscono un 404 in questo caso.

Vorrei copiare Google.

Si potrebbe sostenere che a 404 Not Founddovrebbe essere usato poiché non è stato possibile trovare la risorsa specificata.

Uso spesso un errore 403 proibito. Il ragionamento è che la richiesta è stata compresa, ma non ho intenzione di fare come richiesto (perché le cose sono sbagliate). L'entità response spiega cosa non va, quindi se la risposta è una pagina HTML, i messaggi di errore si trovano nella pagina. Se si tratta di una risposta JSON o XML, le informazioni sull'errore sono presenti.

Da rfc2616 :

10.4.4 403 Proibito

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla.
L'autorizzazione non aiuterà e la richiesta NON DOVREBBE essere ripetuta.
Se il metodo di richiesta non era HEAD e il server desidera rendere
pubblico il motivo per cui la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità. Se il server non desidera rendere disponibili queste informazioni al client, è
possibile utilizzare invece il codice di stato 404 (Not Found).

Solo per utilizzare ASP.NET Core come riferimento o esempio, ASP.NET Core ti consente di impilare un controller con azioni, ecco come appare l'azione "Dettagli".

    // GET: Cars/Details/5
    public async Task<IActionResult> Details(int? id)
    {
        if (id == null)
        {
            return NotFound();
        }

        var car = await _context.Cars.FirstOrDefaultAsync(m => m.CarId == id);
        if (car == null)
        {
            return NotFound();
        }

        return View(car);
    }

Se il parametro idnon è impostato, restituisce 404 Not Found.

Restituisce un 404 , il che significa che non è stato possibile trovare la risorsa.

Prova a modificare un URL di un sito che contiene un ID. Ne ho provati alcuni:

• problema repo gitub
• pagina di confluenza
• vista del prodotto amazon
• elenco ebay
• articolo di notizie bbc

Tutti restituiscono 404, anche perché quegli sviluppatori stanno interpretando correttamente lo standard, cosa che la risposta qui e molti altri non lo sono!

Vorrei andare con un 403.

Da RFC 2616 - Hypertext Transfer Protocol - HTTP / 1.1

403 proibito

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla. L'autorizzazione non aiuterà e la richiesta NON DOVREBBE essere ripetuta. Se il metodo di richiesta non era HEAD e il server desidera rendere pubblico il motivo per cui la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità. Se il server non desidera rendere disponibili queste informazioni al client, è possibile utilizzare invece il codice di stato 404 (Not Found).

Dovresti descrivere la ragione del fallimento nella tua risposta. Se preferisci non farlo, usa solo 404.