Explicații privind eroarea HTTP 422 „Conținut imposibil de procesat”: validarea formularelor, datele transmise prin API și soluții

Codul de eroare HTTP 422 "Conținut imposibil de procesat" înseamnă că serverul a primit o solicitare pe care a putut-o citi, dar datele trimise nu au putut fi procesate. Formatul solicitării este valid la nivel de bază, însă una sau mai multe valori nu trec de validare sau intră în conflict cu o regulă impusă de aplicație.

Acest statut apare adesea în formulare, procese de finalizare a comenzii și API-uri. Cererea a ajuns la etapa corectă de procesare, așa că următorul pas este să se verifice conținutul și regula care a respins-o.

Ce se întâmplă când un server returnează 422?

O cerere parcurge mai multe etape de procesare. Mai întâi, serverul primește cererea și îi citește structura. Apoi verifică valorile trimise în raport cu regulile de validare și regulile aplicației. Un răspuns 422 aparține celei de-a doua etape: cererea poate fi citită, dar conținutul ei nu este acceptabil pentru operațiunea solicitată.

De exemplu, un formular poate conține toate câmpurile așteptate și totuși să returneze codul 422 deoarece o valoare obligatorie este goală, o valoare are un format incorect sau două câmpuri nu sunt în concordanță. O API poate primi o sarcină utilă structurată corect, ale cărei valori nu pot fi utilizate pentru acțiunea solicitată.

Care erori declanșează de obicei HTTP 422?

• Datele obligatorii lipsesc sau sunt goale. Un formular sau o operațiune API poate necesita o valoare pe care solicitarea nu o furnizează.
• O valoare are un format nevalid. Câmpul este prezent, dar conținutul său nu corespunde formatului așteptat de aplicație.
• O valoare se află în afara unui interval sau set permis. Opțiunea, suma sau altă valoare trimisă nu este acceptată de regula de validare.
• Câmpurile asociate sunt în conflict. Câmpurile individuale pot părea valide, dar combinația lor nu respectă regulile formularului sau ale procesului.
• O regulă de afaceri respinge operațiunea. Datele pot fi corecte din punct de vedere structural, dar acțiunea solicitată nu este permisă conform regulilor fluxului respectivei aplicații.

Răspunsul exact depinde de aplicație. Un răspuns 422 util identifică câmpul sau regula afectată fără a dezvălui detalii interne.

În ce fel 422 diferă de o cerere formatată incorect

O solicitare incorectă eșuează în timp ce serverul încearcă să citească sau să interpreteze solicitarea în sine. Serverul nu poate utiliza structura solicitării așa cum a fost trimisă. Un răspuns 422 apare mai târziu în proces: serverul a citit solicitarea, dar valorile nu trec de validare sau de o regulă de afaceri.

Această distincție modifică calea de diagnosticare. Pentru un răspuns 422, începeți cu valorile trimise și regulile de validare. Nu începeți prin a trata cererea ca fiind ilizibilă, cu excepția cazului în care jurnalele indică o eroare separată de parsare sau de transport.

Dimensiunea cererii reprezintă o altă limită. Codul HTTP 413 "Conținut prea mare" înseamnă că un server sau o altă parte a traseului cererii a refuzat o cerere deoarece dimensiunea acesteia a depășit limita permisă. Cererea poate conține un fișier, date de formular, o temă, un plugin, o copie de rezervă sau o altă încărcătură de mari dimensiuni. Consultați Explicația codului de eroare HTTP 413 "Conținut prea mare" pentru acest caz.

Cum se diagnostichează un răspuns 422

1. Înregistrați solicitarea care a eșuat. Notați pagina sau punctul final al API-ului, acțiunea efectuată și ora la care a apărut eroarea. În cazul unei integrări, păstrați corpul răspunsului și identificatorul solicitării, dacă acesta este furnizat.
2. Inspectați conținutul răspunsului. Verificați fiecare câmp trimis de formular sau de client. Asigurați-vă că câmpurile obligatorii conțin valori, că numele câmpurilor corespund cu cele așteptate și că valorile respectă formatul așteptat.
3. Verificați împreună valorile corelate. Examinați câmpurile care depind unele de altele, cum ar fi selecțiile și detaliile asociate acestora. Un cod 422 poate rezulta din utilizarea unei valori valide împreună cu o valoare incompatibilă în altă parte a aceleiași solicitări.
4. Verificați jurnalele serverului. Găsiți înregistrarea corespunzătoare aceluiași punct final și aceleiași ore. Căutați câmpul respins, mesajul de validare, numele regulii sau rezultatul regulii de afaceri. Jurnalul ar trebui să vă ajute să corelați răspunsul cu verificarea de pe partea serverului care a respins datele.
5. Comparați clientul cu regulile de validare. Formularul sau integrarea ar trebui să trimită aceleași câmpuri obligatorii și valori acceptate pe care le așteaptă serverul. Actualizați clientul atunci când regulile sale sau maparea câmpurilor nu corespund cu cele ale serverului.
6. Testați solicitarea corectată. Trimiteți mai întâi cel mai mic set valid de date. Apoi adăugați câmpurile opționale sau datele suplimentare de finalizare a comenzii, câte o parte pe rând. Acest lucru ajută la identificarea valorii sau combinației care provoacă respingerea.

Formulare și fluxuri de finalizare a comenzii

Pentru un formular de pe un site web, afișați rezultatul validării lângă câmpul afectat, atunci când este posibil. Păstrați valorile trimise disponibile, astfel încât utilizatorul să nu fie nevoit să completeze din nou întregul formular. Mesajul ar trebui să descrie corectura într-un limbaj simplu, de exemplu că lipsește o valoare obligatorie sau că o combinație selectată nu este disponibilă.

Fluxurile de finalizare a comenzii necesită aceeași gestionare la nivel de câmp. Validați datele obligatorii ale comenzii înainte de a le trimite, apoi gestionați un cod de eroare 422 pe partea serverului atunci când validarea finală respinge valorile trimise. Nu tratați o cerere de finalizare a comenzii respinsă ca pe o comandă reușită. Afișați un mesaj clar de corectare și permiteți clientului să trimită datele actualizate.

API-uri și integrări

Un client API ar trebui să trateze codul 422 ca pe un răspuns de corectare a datelor. Înregistrați punctul final, forma încărcăturii, corpul răspunsului și detaliile de validare fără a înregistra valori sensibile. Clientul poate apoi corecta câmpurile afectate și trimite din nou solicitarea.

Răspunsurile API ar trebui să utilizeze o structură stabilă pentru erorile de validare. Includeți un mesaj general clar și, acolo unde este cazul, o listă a câmpurilor afectate. Evitați returnarea urmelor de stivă, a detaliilor bazei de date, a datelor de autentificare sau a numelor regulilor interne care nu ajută clientul să corecteze solicitarea.

Cum să preveniți erorile 422 repetate

• Asigurați-vă că verificările efectuate de client sunt aliniate cu validarea de pe server.
• Marcați clar câmpurile obligatorii și validați-le înainte de trimitere.
• Utilizați aceleași denumiri de câmpuri și formate de valori acceptate în toate formularele, API-urile și integrările.
• Validați câmpurile dependente ca grup, nu doar câte un câmp pe rând.
• Afișați mesaje de eroare specifice și sigure, care identifică corectarea fără a dezvălui detalii interne.
• Testați datele de intrare valide, incomplete, formatate incorect și conflictuale înainte de a lansa un formular sau o integrare.

Un răspuns 422 indică faptul că solicitarea a ajuns la aplicație, dar datele sale nu au respectat regulile de procesare. Analizarea datelor transmise, a jurnalelor serverului și a regulilor de validare oferă, de obicei, cea mai clară cale către corectare.