400 ir 422 POST duomenų atsakymai

Bandau išsiaiškinti, koks teisingas būsenos kodas turėtų būti grąžintas skirtingais scenarijais su REST API, su kuriuo dirbau. Tarkime, aš turiu pasekmę, kuri leidžia POST pirkimus JSON formatu. Tai atrodo taip:

 { "account_number": 45645511, "upc": "00490000486", "price": 1.00, "tax": 0.08 } 

Ką turėčiau grąžinti, jei klientas atsiunčia „sales_tax“ (vietoj numatomo „mokesčio“). Šiuo metu grįžiu į 400. Bet aš pradėjau paklausti apie tai. Ar tikrai turėčiau grįžti į 422? Aš turiu galvoje, tai yra JSON (kuris yra palaikomas), ir jis yra galiojantis JSON, jis tiesiog neturi visų reikiamų laukų.

260
21 апр. nustatė David S balandžio 21 d 2013-04-21 20:13 '13, 20:13, 2013-04-21 20:13
@ 9 atsakymai

400 „Bad Request “ dabar bus geriausias HTTP / 1.1 protokolas jūsų naudojimui.

Jūsų klausimo metu (ir mano pradiniame atsakyme) RFC 7231 nebuvo ; tuo metu aš prieštaravau dėl 400 Bad Request , nes RFC 2616 sakė (su mano akcentu):

Prašymą serveris negalėjo suprasti dėl netinkamos sintaksės .

ir jūsų apibūdintas prašymas yra sintaksiškai galiojantis JSON, kuris yra sintaksiškai teisingas HTTP, todėl serveris neturi sintaksės problemų prašymas.

Tačiau, kaip pastebėjo Lee Saferet pastabose , RFC 7231, kuris pasenęs RFC 2616, neapima šio apribojimo :

400 (blogos užklausos) būsenos kodas rodo, kad serveris negali apdoroti užklausos, nes jis suvokiamas kaip kliento klaida (pvz., Neteisingos užklausos sintaksė, neteisinga užklausos pranešimo generavimas arba klaidingų užklausų nukreipimas).


Tačiau prieš šį perrašymą (arba jei norite, kad RFC 7231 būtų tik pasiūlytas standartas dabar), 422 Unprocessable Entity neatrodo neteisingas jūsų HTTP būsenos kodas, nes, kaip įvadą į RFC 4918, jis sako:

Nors HTTP / 1.1 pateikiami būsenos kodai yra pakankami, kad būtų galima apibūdinti daugumą klaidų, susiduriančių naudojant WebDAV metodus, yra tam tikrų klaidų, kurios nepatenka į esamas kategorijas. Ši specifikacija apibrėžia papildomus būsenos kodus, sukurtus WebDAV metodams (11 skyrius)

Ir aprašymas 422 sako:

Būsenos kodas 422 (neapdorotas objektas) reiškia, kad serveris supranta užklausos objekto turinio tipą (todėl 415 (Nepalaikomas laikmenos tipas) netinka), ir užklausos objekto sintaksė yra teisinga (todėl 400 (nepavykusių užklausų) būsenos kodas netinka), bet ne galėjo apdoroti pateiktas instrukcijas.

(Atkreipkite dėmesį į sintaksės nuorodą, manau, kad 7231 iš dalies yra pasenęs 4918)

Tai skamba lygiai taip pat, kaip ir jūsų situacija, bet tik kilus abejonėms: daugiau

Pavyzdžiui, ši klaida gali atsirasti, jei XML užklausos korpuse yra gerai suformuota (tai yra sintaksiškai teisinga), bet semantiškai klaidinga XML instrukcija.

(Pakeiskite „XML“ su „JSON“ ir manau, kad galime eiti kartu su jūsų situacija.)

Dabar kai kurie prieštaraus tai, kad RFC 4918 skirta „HTTP išplėtimams, skirstytiems platinti autorizavimą ir patikrinimą (WebDAV)“, ir kad jūs (galbūt) nieko nedarote naudodami „WebDAV“, todėl neturėtumėte nieko iš jo naudoti.

Pasirinkus tarp pirminio standarto klaidos kodo, kuris neabejotinai neapima situacijos, ir vieno iš išplėtimų, kurie tiksliai apibūdina situaciją, norėčiau pasirinkti pastarąjį.

Be to, RFC 4918 21.4 skirsnis reiškia „ IANA Hypertext Transfer Protocol“ (HTTP) būsenos kodo registrą , kuriame galima rasti 422.

Siūlau, kad HTTP klientas arba serveris visiškai naudotų bet kurį būsenos kodą iš šio registro, jei jie tai daro teisingai.


Tačiau su HTTP / 1.1, RFC 7231 turi potraukį, todėl tiesiog naudokite 400 Bad Request !

320
26 нояб. Atsakymas pateikiamas Kristian Glass 26 lapkričio. 2013-11-26 14:26 '13, 14:26, 2013-11-26 14:26

Kad atspindėtų 2015 m.

Elgesio požiūriu abu atsakymų kodai 400 ir 422 bus tvarkomi vienodai klientų ir tarpininkų, todėl jis iš tikrųjų nesuteikia konkrečių skirtumų.

Tačiau tikiuosi, kad šiuo metu 400 yra plačiau naudojamas, be to, HTTPbis specifikacijos pateikiami paaiškinimai labiau tinka dviem valstybės kodams:

  • HTTPbis specifikacija nurodo ketinimą 400 ne tik sintaksės klaidoms. Šiuo metu naudojama platesnė frazė "reiškia, kad serveris negali apdoroti užklausos dėl to, kas suvokiama kaip kliento klaida."
  • 422 Yra konkretus WebDAV plėtinys ir nėra paminėtas RFC 2616 arba naujame „ HTTPbis“ specifikacijoje.

HTTPbis kontekste tai yra HTTP / 1.1 specifikacijos peržiūra, kuri bando paaiškinti sritis, kuriose ji yra neaiški arba nenuosekli. Pasiekus patvirtintą statusą, jis pakeis RFC2616.

30
13 янв. Atsakyta Tom Christie sausio 13 d 2015-01-13 13:16 '15, 13:16 2015-01-13 13:16

Klaidingas prašymas yra teisingas HTTP būsenos kodas jūsų naudojimo atvejui. Kodą apibrėžia HTTP / 0.9-1.1 RFC.

Prašymą serveris negalėjo suprasti dėl netinkamos sintaksės. Klientas PRIVALO pakartoti prašymą be pakeitimų.

http://tools.ietf.org/html/rfc2616#section-10.4.1

422 Neperdirbamas subjektas yra apibrėžtas RFC 4918 - WebDav. Atkreipkite dėmesį, kad yra nedidelis skirtumas, palyginti su 400, žr. Toliau pateiktą cituotą tekstą.

Ši klaida gali atsirasti, jei XML užklausos korpuse yra gerai suformuota (ty sintaksiškai teisinga), bet semantiškai klaidinga XML instrukcija.

Norėdami išlaikyti vienodą sąsają, turite naudoti 422 tik XML atsakymams, taip pat turite palaikyti visus būsenos kodus, apibrėžtus Webdav plėtinyje, ne tik 422.

http://tools.ietf.org/html/rfc4918#page-78

Taip pat žr. „Mark Nottingham“ būsenos kodus:

jos klaida bandant susieti kiekvieną jūsų programos dalį „giliai“ su HTTP būsenos kodais; daugeliu atvejų detalių, kuriuos norite naršyti, lygis yra daug rupesnis. Jei kyla abejonių, naudokite Gerai, jei norite naudoti bendruosius būsenos kodus 200 OK, 400 Bad Request ir 500 Internal Service Error, kai nėra geriau .

Kaip galvoti apie HTTP būsenos kodus

25
23 апр. atsakymas pateikiamas filip26 23 balandžio. 2013-04-23 17:32 '13, 17:32, 2013-04-23 17:32

Nėra teisingo atsakymo, nes tai priklauso nuo užklausos sintaksės apibrėžimo. Svarbiausia, kad jūs:

  • Naudokite atsakymo kodą nuosekliai
  • Įtraukite tiek papildomos informacijos, kiek galite atsakymo įstaigoje, kad padėtų kūrėjui (kūrėjams), naudodami savo API, sužinoti, kas vyksta. =

Prieš kiekvienas šuolis prie manęs, pasakysiu, kad nėra teisingo ar neteisingo atsakymo, leiskite man šiek tiek papasakoti apie tai, kaip aš atėjau prie išvados.

Šiame konkrečiame pavyzdyje OP klausimas susijęs su JSON prašymu, kuriame yra kitoks nei tikėtasi raktas. Dabar gautas rakto pavadinimas yra labai panašus į natūralią kalbą ir tikėtiną raktą, tačiau jis yra visiškai skirtingas ir todėl mašina (paprastai) nepripažįsta jo kaip lygiavertės.

Kaip jau minėjau, lemiamas veiksnys yra tai, ką reiškia sintaksė. Jei prašymas buvo išsiųstas su turinio tipo application/json , tada taip, prašymas yra sintaksiškai teisingas, nes jis galioja su JSON sintakse, bet nėra semantiškai teisingas, nes jis neatitinka tikėtino. (su sąlyga, kad griežtai apibrėžiama, ką nagrinėja užklausa, semantiškai galioja ar ne).

Kita vertus, jei prašymas buvo išsiųstas su tikslesniu tipu application/vnd.mycorp.mydatatype+json tipo application/vnd.mycorp.mydatatype+json tipo application/vnd.mycorp.mydatatype+json , kuris tikriausiai lemia, kokie laukai laukiami, tada sakyčiau, kad prašymas gali būti lengvai sintaksinis. todėl atsakymas yra 400.

Tokiu atveju, kadangi raktas buvo neteisingas, o ne reikšmė, įvyko sintaksės klaida, jei buvo nustatyta galiojančių raktų specifikacija. Jei galiojančių raktų specifikacija nenustatyta arba klaida buvo vertinga, tai bus semantinė klaida.

11
31 янв. atsakymas pateikiamas cdeszaq 31 d 2014-01-31 22:17 '14, 22:17 2014-01-31 22:17

Pirma, tai labai geras klausimas.

Klaidingas prašymas - jei iš prašymo nėra kritinės informacijos

Pavyzdžiui. Autorizacijos antraštės arba turinio antraštės antraštė. Kuris yra būtinas, kad serveris suprastų prašymą. Tai gali skirtis nuo serverio.

422 Ne procesinis subjektas - kai užklausos įstaiga negali būti analizuojama.

Tai yra mažiau nei 400. Prašymas pasiekė serverį. Serveris patvirtino, kad užklausa turi pagrindinę struktūrą. Tačiau užklausos struktūroje pateikta informacija negali būti analizuojama ar suprantama.

Pavyzdžiui. Content-Type: application/xml kai užklausos įstaiga yra JSON.

Čia yra straipsnis su būsenos kodu ir jo naudojimu REST API. https://metamug.com/article/status-codes-for-rest-api.php

4
09 нояб. atsakymas, kurį pateikė user8029840 09 Nov. 2017-11-09 17:20 '17, 17:20 pm 2017-11-09 17:20

422 Žaliavinio subjekto paaiškinimas Atnaujinta: 2017 m. Kovo 6 d

Kas yra 422 neperdirbamas subjektas?

Būsenos kodas 422 įvyksta, kai prašymas yra tinkamai suformuotas, tačiau jo negalima apdoroti semantinėms klaidoms. Šis HTTP statusas buvo įvestas RFC 4918 ir labiau orientuotas į HTTP išplėtimus, skirtus paskirstytam žiniatinklio kūrimui ir versijos valdymui (WebDAV).

Yra tam tikrų nesutarimų dėl to, ar kūrėjai turėtų grąžinti klientams klaidą, lygią 400, palyginti su 422 (dėl išsamesnės informacijos žr. Skirtumus tarp šių dviejų būsenų). Tačiau daugeliu atvejų tai yra nuosekli po to, kai ši būsena 422 turėtų būti grąžinta tik tuo atveju, jei palaikysite „WebDAV“ galimybes.

Toliau galima perskaityti statuso kodą 422, paimtą iš RFC 4918 11.2 skirsnio.

Būsenos kodas 422 (neapdorotas objektas) reiškia, kad serveris supranta užklausos objekto turinio tipą (todėl 415 (Nepalaikomas laikmenos tipas) netinka), ir užklausos objekto sintaksė yra teisinga (todėl 400 (nepavykusių užklausų) būsenos kodas netinka), bet ne galėjo apdoroti pateiktas instrukcijas.

Toliau pateikiamas apibrėžimas:

Pavyzdžiui, ši klaida gali atsirasti, jei XML užklausos korpuse yra gerai suformuota (tai yra sintaksiškai teisinga), bet semantiškai klaidinga XML instrukcija.

400 ir 422 būsenos kodai

Klaidingos užklausos klaidos naudoja būsenos kodą 400 ir turėtų būti grąžintos klientui, jei užklausos sintaksė yra neteisinga, jame yra neteisinga prieiga prie užklausos pranešimų arba klaidingas užklausų nukreipimas. Šis statuso kodas gali atrodyti gana panašus į 422 neperdirbtą, tačiau vieną nedidelę informacijos dalį, kuri išsiskiria tuo, kad užklausos objekto sintaksė klaidai 422 yra teisinga, o prašymo, generuojančio klaidą 400, sintaksė yra neteisinga.

Būsenos 422 naudojimas turėtų būti rezervuotas tik specialios paskirties atvejais. Daugeliu kitų atvejų, kai kliento klaida įvyko dėl iškraipytos sintaksės, turėtų būti naudojamas „400 Bad Bad“ statusas.

https://www.keycdn.com/support/422-processable-entity/

3
13 июля '17 в 8:06 2017-07-13 08:06 Atsakymą davė Clojurevangelist liepos 17 d. 17 d. 08:06 2017-07-13 08:06

Jūsų atvejis: „ HTTP 400 yra teisingas jūsų atvejo kodas pagal „REST“, nes jis sintaksiškai neteisingas siųsti „ sales_tax vietoj tax , nors ir galiojantis JSON. Tai dažniausiai atlieka dauguma serverių pusės, kai JSON atitinka objektus. Tačiau yra keletas REST diegimų, kurie ignoruoja naują JSON objekto key . Tokiu atveju naudotojo apibrėžta content-type specifikacija priimant tik galiojančius laukus gali būti vykdoma serverio pusėje.

Idealus 422 scenarijus:

Idealiame pasaulyje 422 yra pageidautinas ir paprastai priimtinas siųsti kaip atsakymą, jei serveris supranta užklausos objekto turinio tipą ir prašymo objekto sintaksė yra teisinga, bet negalėjo apdoroti duomenų dėl savo semantiškai klaidingo.

400–422 situacijos:

Atminkite, kad atsakymo kodas 422 yra išplėstinis HTTP būsenos kodas (WebDAV). Vis dar yra tam tikrų HTTP klientų / sąsajų bibliotekų, kurios nėra pasirengusios valdyti 422. Joms tai yra taip paprasta, kaip „HTTP 422, tai neteisinga, nes tai nėra HTTP“. Paslaugų požiūriu 400 nėra visiškai specifinis.

Įmonės architektūroje paslaugos teikiamos daugiausia paslaugų lygmeniu, pvz., SOA, IDM ir kt. Paprastai jie aptarnauja kelis klientus, pradedant nuo labai senų gimtųjų klientų iki naujausių HTTP klientų. Jei vienas iš klientų nesusijęs su HTTP 422, parametrai yra tai, kad klientas prašo atnaujinti arba pakeisti atsakymo kodą į HTTP 400 visiems. Mano patirtimi, šiomis dienomis tai yra labai reti, bet vis dar įmanoma. Todėl prieš priimant sprendimą dėl HTTP atsakymo kodų visada reikia kruopščiai išnagrinėti jūsų architektūrą.

Norėdami susidoroti su šia situacija, paslaugų lygiai paprastai naudoja versioning arba sąrankos configuration vėliavą griežtiems „HTTP“ atitikties klientams siųsti 400 ir išsiųsti 422 kitiems. Taigi jie užtikrina esamų naudotojų atgalinį suderinamumą, tačiau kartu suteikia galimybę naujiems klientams vartoti HTTP 422.


Naujausiame „ RFC7321“ naujinime rašoma:

 The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (eg, malformed request syntax, invalid request message framing, or deceptive request routing). 

Tai patvirtina, kad serveriai gali siųsti HTTP 400 už neteisingą užklausą. 400 nebėra tik sintaksės klaida , bet 422 vis dar yra teisingas atsakymas, jei klientai gali ją tvarkyti.

1
22 февр. Atsakymą pateikė YuVi vasario 22 d. 2017-02-22 21:21 '17 prie 21:21 2017-02-22 21:21

Atvejo analizė: GitHub API

https://developer.github.com/v3/#client-errors

Galbūt kopijavimas iš žinomų API yra protinga idėja:

API skambučiuose, kurie gauna užklausų įstaigas, yra trys galimi klientų klaidų tipai:

Neteisingo JSON siuntimo rezultatas bus 400 blogų užklausų.

 HTTP/1.1 400 Bad Request Content-Length: 35 {"message":"Problems parsing JSON"} 

Neteisingas JSON reikšmės siuntimas bus atsakas į 400 blogų užklausų.

 HTTP/1.1 400 Bad Request Content-Length: 40 {"message":"Body should be a JSON object"} 

Neteisingų laukų siuntimas sukels 422 neapdorojamo subjekto atsakymą.

 HTTP/1.1 422 Unprocessable Entity Content-Length: 149 { "message": "Validation Failed", "errors": [ { "resource": "Issue", "field": "title", "code": "missing_field" } ] } 
0
17 сент. Ciro Santilli atsakymas 改造 改造 中心 六四 事件 法轮功 17 sep . 2018-09-17 11:46 '18, 11:46 2018-09-17 11:46

Tiesą sakant, turėtumėte grąžinti „200 OK“ ir atsakymo įstaigoje - pranešimą apie tai, kas atsitiko su paskelbtais duomenimis. Tada galite kreiptis į savo programą, kad suprastumėte pranešimą.

Faktas yra tai, kad HTTP būsenos kodai yra būtent HTTP būsenos kodai. Ir jie turėtų būti prasmingi tik transporto lygmeniu, o ne paraiškų lygmeniu. Taikymo sluoksnis niekada net nežino, kad naudojamas HTTP. Jei perjungsite transportavimo sluoksnį iš HTTP į Homing Pigeons, tai neturės įtakos jūsų programos sluoksniui.

Leiskite jums pateikti ne virtualų pavyzdį. Tarkime, jūs įsimylėjote mergaitę ir ji myli jus, bet jos šeima persikelia į visiškai kitokią šalį. Ji suteikia jums naują el. Pašto adresą. Žinoma, jūs nusprendėte siųsti jai meilės laišką. Taigi rašote savo laišką, įdėkite jį į voką, parašykite savo adresą ant voko, antspauduokite jį ir išsiųskite. Dabar apsvarstykite šiuos scenarijus.

  • Pamiršote parašyti gatvės pavadinimą. Jūs gausite neatidarytą laišką su pranešimu, kuriame nurodoma, kad adresas neteisingas. Nepavyko apdoroti užklausos, o pašto skyrius negali jo apdoroti. Tai atitinka „400 blogo užklausos“ gavimą.
  • Taigi, pataisote adresą ir vėl išsiųsite laišką. Bet dėl ​​tam tikrų nesėkmių, jūs apskritai klaidingai parašėte gatvės pavadinimą. Jūs vėl gausite laišką, kuriame nurodoma, kad adresas neegzistuoja. Tai atitinka „404 nerasta“.
  • Dar kartą ištaisote adresą, o šį kartą galėsite teisingai užrašyti adresą. Jūsų draugė gauna laišką ir rašo jums. Tai atitinka „200 OK“. Tačiau tai nereiškia, kad jums patiks tai, ką ji parašė savo laiške. Tai tiesiog reiškia, kad ji gavo jūsų pranešimą ir atsakė už jus. Kol neatsidarysite voko ir neperskaitėte jos laiško, jūs negalite žinoti, ar jūs nuobodžiate, ar norite su jumis dalyvauti.

Trumpai tariant, „200 OK“ grąžinimas nereiškia, kad serverio taikymas jums yra geras. Tai tik reiškia, kad jis turi naujienų.

PS: statuso kodas 422 prasmingas tik „WebDAV“ kontekste. Jei neveikia su WebDAV, tada 422 turi tokią pačią standartinę vertę kaip bet kuris kitas nestandartinis kodas =, kuris nėra.

-7
08 марта '17 в 3:36 2017-03-08 03:36 atsakymą pateikė „ GoFree“ kovo 8 d. 17 d. 3:36 2017-03-08 03:36