Ik denk aan 412 (voorwaarde mislukt) maar er is misschien een betere standaard?
Antwoord 1, autoriteit 100%
Status 422 lijkt het meest geschikt op basis van de specificatie.
De statuscode 422 (onverwerkbare entiteit) betekent de server
begrijpt het inhoudstype van de verzoekentiteit (vandaar a
415 (niet-ondersteund mediatype) statuscode is ongepast), en de
syntaxis van de aanvraagentiteit is correct (dus een 400 (slechte aanvraag)
statuscode is ongepast) maar kon de ingesloten . niet verwerken
instructies. Deze foutconditie kan bijvoorbeeld optreden als een XML
request body bevat goed gevormde (d.w.z. syntactisch correct), maar
semantisch onjuiste, XML-instructies.
Ze stellen dat een misvormde xml een voorbeeld is van een slechte syntaxis (waarom een 400 wordt gevraagd). Een misvormde querystring lijkt hier analoog aan, dus 400 lijkt niet geschikt voor een goedgevormde querystring die een parameter mist.
UPDATE@DavidV wijst er terecht op dat deze specificatie voor WebDAV is, niet voor core HTTP. Maar sommige populaire niet-WebDAV API’s gebruiken toch 422, bij gebrek aan een betere statuscode (zie dit).
Antwoord 2, autoriteit 48%
Ik weet niet zeker of er een vaste standaard is, maar ik zou 400 Bad Requesthebben gebruikt, volgens de nieuwste HTTP-specificatie (van 2014) documenteert als volgt:
6.5.1. 400 slecht verzoek
De 400 (Bad Request) statuscode geeft aan dat de server niet kan of
zal het verzoek niet verwerken vanwege iets dat wordt gezien als
een clientfout (bijv. verkeerd opgemaakte verzoeksyntaxis, ongeldig verzoek
berichtframing of misleidende routering van verzoeken).
Antwoord 3, autoriteit 8%
De WCF APIin .NET verwerkt ontbrekende parameters door een HTTP 404“Endpoint Not Found”-fout bij gebruik van de webHttpBinding.
De 404 Not Foundkan logisch zijn als u de naam van uw webservicemethode samen met de parameterhandtekening overweegt. Dat wil zeggen, als u een webservicemethode LoginUser(string, string)blootlegt en u vraagt LoginUser(string)aan, wordt deze laatste niet gevonden.
In principe zou dit betekenen dat de webservicemethode die u aanroept, samen met de parameterhandtekening die u hebt opgegeven, niet kan worden gevonden.
10.4.5 404 niet gevonden
De server heeft niets gevonden dat overeenkomt met de Request-URI. Nee
er wordt aangegeven of de aandoening tijdelijk is of
permanent.
The 400 Bad Request, als Suggereerde Gert, blijft een geldige antwoordcode, maar ik denk dat deze normaal wordt gebruikt om problemen op een lager niveau aan te geven. Het kan gemakkelijk worden geïnterpreteerd als een misvormd HTTP-verzoek, misschien ontbrekende of ongeldige HTTP-headers, of iets dergelijks.
10.4.1 400 ongeldig verzoek
Het verzoek kon niet worden begrepen door de server vanwege een verkeerde indeling
syntaxis. De klant MOET het verzoek NIET herhalen zonder:
aanpassingen.
Antwoord 4, autoriteit 4%
Je kunt een 400 Bad Request-code sturen. Het is een van de meer algemene 4xx-statuscodes, dus je kunt het gebruiken om te betekenen wat je bedoelt: de klant stuurt een verzoek waarin informatie/parameters ontbreekt die je applicatie nodig heeft om het correct te verwerken.
Antwoord 5
Ik ga meestal voor 422 (onvoldoende entiteit) als iets in de vereiste parameters niet overeenkwam met wat het API-eindpunt vereist (zoals een te kort wachtwoord) maar voor een ontbrekende parameter zou ik voor 406 (onaanvaardbaar).
6
Voor diegenen die geïnteresseerd zijn, retourneert Spring MVC (3.x tenminste) een 400 in dit geval, wat verkeerd lijkt.
Ik heb verschillende Google-URL’s (Accounts.google.com) getest en vereiste parameters verwijderd en ze retourneren in het algemeen een 404 in dit geval.
Ik zou Google kopiëren.
7
Er kan worden betoogd dat een 404 Not Foundmoet worden gebruikt, aangezien de opgegeven resource niet kon worden gevonden.
8
Ik gebruik vaak een 403 verboden fout. De redenering is dat het verzoek werd begrepen, maar ik ga niet als gevraagd (omdat er het mis is). De respons-entiteit legt uit wat er aan de hand is, dus als het antwoord een HTML-pagina is, staan de foutmeldingen op de pagina. Als het een antwoord van JSON of XML is, is de foutinformatie daarin.
van rfc2616 :
10.4.4 403 Verboden
De server begreep het verzoek, maar weigert het te vervullen.
Autorisatie helpt niet en het verzoek mag niet worden herhaald.
Als de aanvraagmethode niet hoofd was en de server wenst te maken
publiek waarom niet is voldaan, zou het de
Reden voor de weigering in de entiteit. Als de server niet wenst
Maak deze informatie beschikbaar voor de klant, de statuscode 404
(Niet gevonden) kan in plaats daarvan worden gebruikt.