Ik heb een JSON-verzoek dat ik op een HTTP-URL plaats.
Moet dit worden behandeld als 400waar het veld requestedResourcebestaat maar "Roman"een ongeldige waarde is voor dit veld?
[{requestedResource:"Roman"}]
Moet dit worden behandeld als 400waar het veld "blah"helemaal niet bestaat?
[{blah:"Roman"}]
Antwoord 1, autoriteit 100%
Een 400 betekent dat het verzoek onjuist is opgemaakt. Met andere woorden, de datastroom die door de client naar de server werd gestuurd, voldeed niet aan de regels.
In het geval van een REST API met een JSON-payload, worden 400’s meestal, en terecht, zou ik zeggen, gebruikt om aan te geven dat de JSON op de een of andere manier ongeldig is volgens de API-specificatie voor de service.
Volgens die logica zouden beide scenario’s die u heeft opgegeven 400’s moeten zijn.
Stel je voor dat dit XML was in plaats van JSON. In beide gevallen zou de XML nooit de schemavalidatie doorstaan, hetzij vanwege een niet-gedefinieerd element of een onjuiste elementwaarde. Dat zou een slecht verzoek zijn. Zelfde deal hier.
Antwoord 2, autoriteit 21%
Van w3.org
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 3, autoriteit 15%
Het selecteren van een HTTP-responscode is een vrij gemakkelijke taak en kan worden beschreven met eenvoudige regels. Het enige lastige deel dat vaak wordt vergeten, is paragraaf 6.5 van RFC 7231:
Behalve bij het reageren op een HEAD-verzoek, MOET de server een
weergave met uitleg van de foutsituatie,
en of het een tijdelijke of permanente aandoening is.
Regels zijn als volgt:
- Als het verzoek succesvol was, retourneer dan 2xx-code (3xx voor omleiding). Als er een interne logische fout op een server is opgetreden, retourneer dan 5xx. Als er iets mis is in het verzoek van de klant, retourneer dan de 4xx-code.
- Bekijk de beschikbare antwoordcode van de geselecteerde categorie. Als een van hen een naam heeft die goed bij uw situatie past, kunt u die gebruiken. Anders gewoon terugvallen op x00-code (200, 400, 500). Als je twijfelt, val terug naar x00-code.
- Geef een foutbeschrijving terug in de hoofdtekst van het antwoord. Voor 4xx-codes moet het voldoende informatie bevatten voor de klantontwikkelaar om de reden te begrijpen en de klant te repareren. Voor 5xx mogen vanwege veiligheidsredenen geen details worden onthuld.
- Als de klant verschillende fouten moet onderscheiden en er verschillende reacties op moeten hebben, definieer dan een machineleesbaar en uitbreidbaar foutformaat en gebruik het overal in uw API. Het is een goede gewoonte om dat vanaf het begin te doen.
- Houd er rekening mee dat clientontwikkelaars vreemde dingen kunnen doen en proberen strings te ontleden die u terugstuurt als een voor mensen leesbare beschrijving. En door de snaren te veranderen, verbreek je zulke slecht geschreven clients. Geef dus altijd een machineleesbare beschrijving en probeer te voorkomen dat aanvullende informatie in tekst wordt vermeld.
Dus in jouw geval had ik een 400-fout geretourneerd en zoiets als dit als “Roman” wordt verkregen uit gebruikersinvoer en de klant een specifieke reactie moet hebben:
{
"error_type" : "unsupported_resource",
"error_description" : "\"Roman\" is not supported"
}
of een meer algemene fout, als een dergelijke situatie een slechte logische fout in een client is en niet wordt verwacht, tenzij de ontwikkelaar iets verkeerd heeft gemaakt:
{
"error_type" : "malformed_json",
"error_description" : "\"Roman\" is not supported for \"requestedResource\" field"
}
Antwoord 4, autoriteit 6%
In geen van beide gevallen is de “syntaxis onjuist opgemaakt”. Het is de semantiek die fout is. Daarom is IMHO een 400 ongepast. In plaats daarvan zou het gepast zijn om een 200 terug te sturen samen met een of ander foutobject zoals { "error": { "message": "Unknown request keyword" } }of wat dan ook.
Houd rekening met het (de) verwerkingspad(en) van de client. Een fout in de syntaxis (bijv. ongeldige JSON) is een fout in de logica van het programma, met andere woorden een soort bug, en moet dienovereenkomstig worden afgehandeld, op een manier die vergelijkbaar is met bijvoorbeeld een 403; met andere woorden, er is iets ergs misgegaan.
Een fout in een parameterwaarde daarentegen is een fout in de semantiek, misschien te wijten aan slecht gevalideerde gebruikersinvoer. Het is geen HTTP-fout (hoewel ik veronderstel dat het een 422) zou kunnen zijn. Het verwerkingspad zou anders zijn.
In jQuery zou ik bijvoorbeeld liever geen enkele fouthandler hoeven te schrijven die zowel zaken als 500 en een app-specifieke semantische fout behandelt. Andere frameworks, bijvoorbeeld Ember, behandelen HTTP-fouten zoals 400’s en 500’s identiek als grote fouten, waarbij de programmeur moet detecteren wat er aan de hand is en vertakt, afhankelijk van of het een “echte” fout is of niet.
Antwoord 5, autoriteit 5%
Het gebruik van 400statuscodes voor een ander doel dan om aan te geven dat het verzoekonjuist is opgemaakt, is gewoon verkeerd.
Als de payload van het verzoek een bytereeks bevat die niet kan worden geparseerd als application/json(als de server dat gegevensformaat verwacht), is de juiste statuscode 415:
De server weigert het verzoek te verwerken omdat de entiteit van
het verzoek heeft een indeling die niet wordt ondersteund door de gevraagde bron voor:
de gevraagde methode.
Als de payload van het verzoek syntactisch correct maar semantisch incorrect is, kan de niet-standaard 422responscode worden gebruikt, of de standaard 403statuscode:
De server heeft het verzoek begrepen, maar weigert eraan te voldoen.
Autorisatie helpt niet en het verzoek MAG NIET worden herhaald.
Antwoord 6, autoriteit 2%
Denk na over verwachtingen.
Als client-app verwacht je te weten of er iets misgaat aan de serverkant. Als de server een fout moet genereren wanneer blahontbreekt of de requestedResource-waarde onjuist is, dan zou een 400-fout passend zijn.
Antwoord 7, autoriteit 2%
Controleer eerst de URL, deze kan verkeerd zijn, als deze correct is, controleer dan de hoofdtekst van het verzoek dat u verzendt, de mogelijke oorzaak is dat het verzoek dat u verzendt de juiste syntaxis mist.
Om uit te werken, controleert u op speciale tekens in de verzoekreeks. Als het (speciale teken) wordt gebruikt, is dit de hoofdoorzaak van deze fout.
probeer het verzoek te kopiëren en analyseer alle taggegevens.
Antwoord 8, autoriteit 2%
Als aanvulling, voor degenen die hetzelfde probleem als het mijne zouden kunnen tegenkomen, gebruik ik $.ajaxom formuliergegevens naar de server te posten en ik heb ook de 400fout in eerste instantie.
Stel dat ik een javascript-variabele heb,
var formData = {
"name":"Gearon",
"hobby":"Be different"
};
Gebruik variabele formDataniet rechtstreeks als de waarde van sleutel datazoals hieronder:
$.ajax({
type: "post",
dataType: "json",
url: "http://localhost/user/add",
contentType: "application/json",
data: formData,
success: function(data, textStatus){
alert("Data: " + data + "\nStatus: " + status);
}
});
Gebruik in plaats daarvan JSON.stringify om de formDatain te kapselen zoals hieronder:
$.ajax({
type: "post",
dataType: "json",
url: "http://localhost/user/add",
contentType: "application/json",
data: JSON.stringify(formData),
success: function(data, textStatus){
alert("Data: " + data + "\nStatus: " + status);
}
});
Hoe dan ook, zoals anderen hebben geïllustreerd, is de fout dat de server het verzoek niet kon herkennen vanwege een onjuiste syntaxis, ik breng gewoon een instantie naar voren tijdens de praktijk. Hoop dat het iemand zou helpen.
Antwoord 9
Dit doet me denken aan een gebruikelijke dialoog met anderen: “Ik begrijp het – ik ben het er gewoon niet mee eens”
400 betekent dat de server het niet heeft begrepen
200 betekent dat de server het verzoek precies heeft begrepen en volledig heeft verwerkt.
Als een server 200 retourneert, zegt hij: “Ik heb begrepen wat u vraagt, ik heb het zonder onverwachte fouten verwerkt en hier is mijn juiste antwoord”
200 betekent dat u het antwoord dat in het antwoord is verzonden, kunt vertrouwen. Misschien is het antwoord “Romeinen zijn niet toegestaan” – maar toch is het een goed antwoord, gegenereerd zonder onverwachteproblemen.
200 geeft geen informatie over verwachte fouten of afgehandelde uitzonderingen – omdat dat geen deel uitmaakt van het berichttransportproces. Dit zijn statuscodes over HTTP, de Status van het Transport zelf.
Ik ben van mening dat het vervagen van de grens tussen ‘Transport/Communicatie’ en ‘Verwerking’ moet worden vermeden.
Voor degenen die de voorkeur geven aan HTTP-codes om een probleem bij de verwerking aan te geven (het gedeelte ‘Ik ben het er niet mee eens’), lijkt 409-conflict het meest van toepassing te zijn op ‘Romeinen niet toegestaan’
RFC 7231 409-conflict
Conflict betekent eigenlijk “gebrek aan overeenstemming”, toch?
Het maakt niet uit wat je kiest voor HTTP-antwoordcode, het lijkt erop dat iedereen het erover eens is dat je antwoord moet uitleggen waarom het is mislukt en wat je moet doen om het op te lossen. In het geval van Roman, misschien een lijst met acceptabele waarden voor het veld retourneren?