Lỗi 422 Unprocessable Content: đọc lỗi từng trường của API

Lỗi 422 Unprocessable Content là mã HTTP báo máy chủ hiểu request, đọc được dữ liệu, nhưng dữ liệu không qua được kiểm tra nghiệp vụ, ví dụ email sai định dạng hay số lượng ngoài khoảng cho phép. Đổi proxy, đổi IP hay thử lại đều không làm 422 biến mất, vì lỗi nằm ở nội dung gửi đi. ProxyVN dựng một API đặt hàng có schema trên máy lab, gửi năm payload khác nhau đi thẳng và qua proxy, đọc phản hồi theo chuẩn problem details để chỉ ra cách sửa từng trường.

Lỗi 422 Unprocessable Content: lớp nào quyết định hành vi

Ba lớp kiểm tra

Một request gửi dữ liệu tới API đi qua ba lớp kiểm tra. Lớp đầu kiểm kiểu nội dung: máy chủ có nhận dạng dữ liệu này không. Lớp hai kiểm cú pháp: dữ liệu có đọc được không. Lớp ba kiểm ý nghĩa: dữ liệu đọc được có hợp lệ theo quy tắc của ứng dụng không. Mỗi lớp có mã lỗi riêng.

422 nằm ở lớp ba

Tài liệu MDN về 422 ghi máy chủ hiểu kiểu nội dung, cú pháp đúng, nhưng không xử lý được các chỉ thị trong đó. Nói gọn: JSON đọc được, nhưng giá trị không hợp lệ. Trước đây mã này có tên Unprocessable Entity, RFC 9110 đổi thành Unprocessable Content.

Ví dụ điển hình: trường quantity bằng 0 trong khi API chỉ nhận từ 1 tới 100, trường email thiếu ký tự @, trường mã sản phẩm không tồn tại trong hệ thống. JSON vẫn hợp lệ về cú pháp, nhưng đơn hàng không thể tạo.

Nguồn gốc của mã 422

Mã 422 ra đời trong chuẩn WebDAV, phần mở rộng HTTP cho quản lý tệp từ xa, rồi được đưa vào bộ mã chung của HTTP trong RFC 9110. Vì vậy trong một số tài liệu cũ, 422 được nhắc như mã của WebDAV. Ngày nay nó là mã HTTP chuẩn, dùng rộng rãi trong API REST.

Nhiều framework web mới như Rails, Laravel và FastAPI chọn 422 làm mã mặc định cho lỗi kiểm tra dữ liệu. Đó là lý do người dùng tool tự động gặp 422 nhiều hơn so với vài năm trước.

400 và 415 nằm ở lớp trước

415 Unsupported Media Type xảy ra ở lớp một: máy chủ chỉ nhận JSON mà client gửi dạng form. 400 Bad Request thường xảy ra ở lớp hai: JSON bị cắt giữa chừng, thiếu dấu ngoặc, sai dấu phẩy. Bài lỗi 400 Bad Request và lỗi 415 Unsupported Media Type đi sâu hai mã này.

Không phải API nào cũng tách ba mã rõ ràng. Nhiều API trả 400 cho mọi lỗi dữ liệu, kể cả lỗi nghiệp vụ. Nhưng khi API trả 422, đó là tín hiệu rõ: cú pháp đúng, nội dung sai.

Proxy không đứng ở lớp nào trong ba lớp

Proxy HTTP chuyển request đi, không đọc nội dung JSON, không kiểm schema. Với HTTPS, proxy thậm chí không thấy nội dung. Ba lớp kiểm tra đều diễn ra ở máy chủ API.

Lỗi 422 đi qua proxy y nguyên như đi thẳng, nên đổi proxy không bao giờ sửa được 422. Đây là điểm người dùng proxy hay nhầm khi thấy lỗi xuất hiện trong lúc chạy tool qua proxy.

Khi nào người dùng proxy gặp 422

Người dùng proxy gặp 422 chủ yếu trong ba việc. Việc thứ nhất là tool tự động đăng ký, đăng bài hay cập nhật thông tin qua API của nền tảng, khi dữ liệu nhập từ tệp có định dạng sai. Việc thứ hai là crawler đẩy dữ liệu đã cào lên hệ thống nội bộ hay dịch vụ lưu trữ. Việc thứ ba là gọi API tìm kiếm với tham số không hợp lệ.

Cả ba việc thường chạy qua proxy, nên lỗi xuất hiện trong log cùng với lỗi kết nối proxy. Người vận hành thấy một loạt lỗi, đổi proxy, lỗi vẫn còn. Biết 422 không liên quan proxy giúp tách ngay nhóm lỗi này ra để xử lý riêng.

Ranh giới với các bài đã có

Bài lỗi 409 Conflict khi gọi API nói về xung đột trạng thái tài nguyên. Bài rate limit API khi dùng proxy nói về giới hạn tần suất. Bài này đi vào lỗi kiểm tra dữ liệu: đọc danh sách lỗi theo trường và sửa payload.

Phân biệt lỗi dữ liệu nghiệp vụ với 400 và 415, đọc errors theo trường khi gặp lỗi 422 Unprocessable Content

Phần này giải thích cấu trúc phản hồi lỗi hay gặp và cách đọc nó để sửa đúng chỗ.

Problem details

RFC 9457 định nghĩa một định dạng chuẩn cho phản hồi lỗi của API, kiểu nội dung application/problem+json. Phản hồi có các trường type, title, status, detail, instance, và cho phép thêm trường mở rộng. Nhiều API đặt danh sách lỗi theo trường vào một trường mở rộng như errors.

API trong lab theo định dạng này. Phản hồi 422 có type trỏ tới mô tả loại lỗi, title Unprocessable Content, status 422 và mảng errors. Mỗi phần tử có field, code và message.

Đọc mảng errors

Mảng errors theo trường

Trường field cho biết trường nào trong payload bị lỗi. Trường code là mã máy đọc được, như range, type, invalid_format, not_found, enum. Trường message là câu cho người đọc. Mã code ổn định hơn message, nên mã client nên dựa vào code để xử lý tự động.

Một phản hồi có thể chứa nhiều lỗi cùng lúc. API tốt kiểm hết các trường và trả mọi lỗi trong một lần, để client sửa một lần. API kém trả lỗi đầu tiên, client sửa xong lại gặp lỗi tiếp theo.

Mã code ổn định hơn message

message thường được dịch theo ngôn ngữ người dùng hoặc sửa câu chữ giữa các phiên bản. Mã nguồn so sánh chuỗi message sẽ hỏng khi API đổi câu. code thì giữ nguyên qua các phiên bản và ngôn ngữ, phù hợp để mã client rẽ nhánh.

Trong lab, message được viết không dấu, còn code là các từ khóa tiếng Anh ngắn. Khi API trả message tiếng Việt có dấu, mã xử lý dựa trên code vẫn chạy y nguyên.

Mỗi API một định dạng

Không có định dạng chung bắt buộc cho errors. GitHub, Stripe, Laravel, FastAPI, Django REST Framework mỗi nơi đặt một kiểu. Có nơi là mảng, có nơi là đối tượng ánh xạ tên trường tới danh sách thông báo, có nơi lồng đường dẫn trường dạng body, items, 0, price. Trước khi viết mã xử lý, đọc tài liệu API hoặc gửi thử một payload sai để xem cấu trúc thật.

Đường dẫn trường lồng nhau

Với payload có mảng và đối tượng lồng, field thường là một đường dẫn: items[2].price hay items, 2, price tùy API. Đường dẫn này chỉ đúng phần tử bị lỗi. Với đơn hàng nhiều dòng, nó cho biết dòng thứ mấy sai mà không cần đoán.

Khi xử lý tự động, chuẩn hóa đường dẫn về một dạng chung trong mã của anh em. Như vậy cùng một hàm báo lỗi dùng được cho nhiều API có cách viết đường dẫn khác nhau.

Lỗi kiểu và lỗi giá trị

Trong lab, quantity bằng chuỗi "2" cho mã type, còn quantity bằng 0 cho mã range. Hai lỗi cùng trường nhưng khác bản chất. Lỗi kiểu thường do client tạo payload sai, như đọc số từ CSV thành chuỗi. Lỗi giá trị thường do dữ liệu đầu vào sai.

Crawler đẩy dữ liệu lên API hay gặp lỗi kiểu, vì dữ liệu cào về ban đầu đều là chuỗi. Bài Pydantic chuẩn hóa dữ liệu crawl có cách ép kiểu trước khi gửi.

Thiết kế lab lỗi 422 Unprocessable Content: phiên bản và phép đo

Lab chạy ngày 29/10/2026 trên Windows 10, Python 3.12.10, requests 2.34.2. API và proxy đều chạy trên 127.0.0.1.

API đặt hàng

API nghe ở cổng 9545, nhận POST /orders với bốn trường: email, quantity, sku, country. Quy tắc: email đúng dạng, quantity là số nguyên từ 1 tới 100, sku thuộc danh sách PRX-VN-01 và PRX-US-02, country thuộc VN, US, SG.

Thứ tự kiểm: kiểu nội dung trước, trả 415 nếu không phải JSON. Cú pháp sau, trả 400 nếu JSON hỏng. Cuối cùng kiểm từng trường, trả 422 với mọi lỗi tìm thấy. Hợp lệ thì trả 201 kèm mã đơn.

Proxy lab

Proxy HTTP ở cổng 9546, không yêu cầu xác thực, chuyển tiếp request và phản hồi. Mục đích là so sánh phản hồi khi đi thẳng và khi qua proxy. Proxy không yêu cầu xác thực để loại 407 khỏi thí nghiệm, chỉ còn lại lỗi do API trả. Với proxy có xác thực, kết quả với 422 vẫn như vậy, chỉ thêm một lớp có thể trả 407 trước khi request tới API.

Ghi log phía API

API lab ghi mỗi request nhận được: đường dẫn, Content-Type và số byte thân. Tổng 13 request khớp với 10 lần gửi chính cộng 3 lần thử lại payload ba. Log này xác nhận mọi request qua proxy đều tới API, proxy không chặn hay sửa gì.

Năm payload

Payload một hợp lệ. Payload hai sai một trường, quantity bằng 0. Payload ba sai cả bốn trường: email thiếu @, quantity là chuỗi, sku không tồn tại, country là JP. Payload bốn là JSON bị cắt giữa chừng. Payload năm gửi đúng dữ liệu nhưng dạng form thay vì JSON.

Mỗi payload gửi hai lần: thẳng và qua proxy. Payload ba gửi thêm ba lần qua proxy để xem thử lại có đổi kết quả không.

Vì sao tự viết API

API thật như GitHub hay Stripe cần tài khoản và khóa, và mỗi lần gửi sai là một request thật vào hệ thống của họ. API tự viết cho phép gửi đủ loại payload sai mà không ảnh hưởng ai, và biết chính xác quy tắc kiểm để đối chiếu kết quả.

Định dạng phản hồi được chọn theo RFC 9457 vì đây là chuẩn chung, nhiều framework mới dùng sẵn. Kết luận về cách đọc errors áp được cho API thật có cấu trúc tương tự, chỉ khác tên trường.

Kết quả kỳ vọng

Năm payload cho năm kết quả: 201, 422 một lỗi, 422 bốn lỗi, 400, 415. Qua proxy cho kết quả giống hệt đi thẳng.

Tái lập lỗi 422 Unprocessable Content: luồng thành công và các ca lỗi có kiểm soát

Phần này đưa mã gửi và bảng kết quả thật.

Mã gửi

import requests
U = "http://127.0.0.1:9545/orders"
payload = {"email": "an-example.com", "quantity": "2", "sku": "PRX-XX-99", "country": "JP"}
r = requests.post(U, json=payload, proxies={"http": "http://127.0.0.1:9546"}, timeout=5)
print(r.status_code, r.headers["Content-Type"])
for e in r.json().get("errors", []):
    print(e["field"], e["code"], e["message"])

Tham số json của requests tự đặt Content-Type là application/json và mã hóa dữ liệu. Dùng data với một dict sẽ gửi dạng form, chính là payload năm.

Bảng kết quả

Bảng: Bảng kết quả

Payload	Đi thẳng	Qua proxy	Kiểu nội dung phản hồi	Nội dung chính
Hợp lệ	201	201	application/json	Mã đơn mới
Sai một trường	422	422	application/problem+json	quantity, range
Sai bốn trường	422	422	application/problem+json	email, quantity, sku, country
JSON hỏng	400	400	application/problem+json	JSON lỗi ở vị trí 42
Gửi dạng form	415	415	application/problem+json	Unsupported Media Type

Trừ mã đơn ở ca hợp lệ, vốn sinh mới mỗi lần, mọi phản hồi qua proxy giống hệt đi thẳng, kể cả từng phần tử trong mảng errors. Máy chủ API nhận tổng cộng 13 request.

Bốn lỗi trong một phản hồi

Payload ba nhận một phản hồi 422 với bốn phần tử:

Bảng: Bốn lỗi trong một phản hồi

field	code	message
email	invalid_format	Email không hợp lệ
quantity	type	Phải là số nguyên
sku	not_found	Mã sản phẩm không tồn tại
country	enum	Chỉ nhận VN, US, SG

Client sửa cả bốn trường theo bảng này trong một lần. Không cần thử từng trường. Nếu API chỉ trả lỗi đầu tiên, cùng payload này sẽ cần bốn lần gửi và bốn lần sửa mới qua được, tốn thời gian và quota.

Ca gửi dạng form

Payload năm gửi đúng bốn trường nhưng dạng application/x-www-form-urlencoded, vì dùng tham số data với một dict. API từ chối ngay ở lớp kiểu nội dung với 415, không kiểm trường nào. Đây là lỗi hay gặp khi chuyển mã từ gửi biểu mẫu web sang gọi API.

Nếu API lỏng hơn và chấp nhận mọi kiểu nội dung, cùng lỗi này có thể hiện thành 422 với thông báo thiếu mọi trường, vì API không đọc được JSON nào. Thấy 422 báo thiếu tất cả các trường cùng lúc là gợi ý kiểm Content-Type trước.

Đọc phản hồi bằng mã

r = requests.post(U, json=payload, timeout=5)
if r.status_code == 422:
    body = r.json()
    loi = {e["field"]: e["code"] for e in body.get("errors", [])}
    if loi.get("quantity") == "type":
        payload["quantity"] = int(payload["quantity"])
    print("can sua:", loi)

Đoạn mã đọc mảng errors thành từ điển trường và mã, rồi xử lý ca có cách sửa rõ là lỗi kiểu của quantity. Các lỗi còn lại in ra để người xem. Cách này tách phần tự sửa được khỏi phần cần quyết định.

Thử lại không đổi kết quả

Gửi payload ba thêm ba lần qua proxy, cả ba đều 422. Không có gì thay đổi giữa các lần, vì dữ liệu không đổi. Logic thử lại tự động áp cho 429, 502, 503 sẽ chỉ tốn request nếu áp cho 422.

JSON hỏng cho 400, không phải 422

Payload bốn cắt giữa chừng, máy chủ không đọc được, trả 400 với vị trí lỗi 42 trong chuỗi. Đây là lỗi cú pháp. Nếu crawler gửi JSON bằng cách ghép chuỗi tay thay vì dùng thư viện mã hóa, lỗi này rất hay gặp.

400 nói "không đọc được", 422 nói "đọc được nhưng sai"; cách sửa nằm ở hai chỗ khác nhau. Với 400, sửa cách tạo JSON. Với 422, sửa giá trị dữ liệu.

Đọc log, gói tin và response để tách lỗi 422 Unprocessable Content với lỗi gần giống

Qua proxy không đổi

Phần này giúp nhận ra nhanh 422 có liên quan proxy hay không, và phân biệt với các mã hay đi cùng.

Bảng phân biệt

Bảng: Bảng phân biệt

Mã	Lớp	Nguyên nhân	Đổi proxy có giúp	Thử lại có giúp
415	Kiểu nội dung	Gửi form thay JSON, sai Content-Type	Không	Không
400	Cú pháp	JSON hỏng, tham số sai dạng	Không	Không
422	Nghiệp vụ	Giá trị không hợp lệ	Không	Không
409	Trạng thái	Xung đột với dữ liệu hiện có	Không	Đôi khi, sau khi đọc lại trạng thái
429	Tần suất	Gửi quá nhanh	Đôi khi, nếu giới hạn theo IP	Có, sau thời gian chờ
403	Quyền	Bị chặn hoặc thiếu quyền	Đôi khi, nếu chặn theo IP	Không

Chỉ hai dòng cuối có thể liên quan proxy, vì máy chủ có thể giới hạn hoặc chặn theo IP. Ba dòng đầu và 409 nằm ở dữ liệu. Bài lỗi 429 khi dùng proxy đi vào ca giới hạn tần suất.

Đọc kiểu nội dung phản hồi

Phản hồi 422 có Content-Type là application/problem+json hoặc application/json, kèm thân có cấu trúc. Phản hồi do proxy tạo ra, như 407 hay 502, thường là HTML hoặc văn bản ngắn của phần mềm proxy. Nhìn kiểu nội dung là biết phản hồi đến từ API hay từ proxy.

Trong lab, mọi phản hồi lỗi đều là application/problem+json từ API. Không phản hồi nào do proxy tạo.

Khi proxy có tường lửa ứng dụng

Một số dịch vụ proxy doanh nghiệp hay cổng bảo mật có lớp kiểm nội dung, chặn request chứa mẫu nghi ngờ. Khi chặn, chúng thường trả 403 hoặc một trang báo lỗi riêng, hiếm khi trả 422. Nếu thấy 422 có thân HTML lạ thay vì JSON của API, kiểm xem có lớp nào ở giữa không.

Với proxy thương mại thông thường dùng cho crawl, lớp này không có. Phản hồi 422 gần như luôn đến từ máy chủ API.

Ghi log thân phản hồi lỗi

Nhiều crawler chỉ ghi mã trạng thái. Với 422, mã trạng thái không đủ, phải ghi cả mảng errors. Ghi tối đa vài trăm ký tự đầu của thân lỗi, cắt bỏ dữ liệu cá nhân nếu có, là đủ để biết trường nào sai.

Khi gửi hàng loạt, nhóm lỗi theo field và code để thấy lỗi nào phổ biến nhất. Một lỗi kiểu xuất hiện ở mọi bản ghi gần như chắc là lỗi chuyển đổi dữ liệu ở crawler, không phải lỗi dữ liệu nguồn.

Xử lý lỗi 422 Unprocessable Content theo bằng chứng và checklist

Checklist lỗi 422

Cách xử lý chia theo người gửi: script gửi tay, crawler đẩy dữ liệu hàng loạt và người làm API.

Với script gửi tay

Trước khi sửa, gửi lại đúng payload đó một lần với log chi tiết để chắc dữ liệu gửi đi là dữ liệu anh em nghĩ. Nhiều lần lỗi nằm ở bước đọc tệp đầu vào, như dòng tiêu đề CSV bị đọc thành dữ liệu, chứ không phải ở giá trị đã kiểm trong đầu.

Đọc mảng errors, sửa từng trường theo field và code, gửi lại. Dùng tham số json của thư viện HTTP thay vì ghép chuỗi. Đảm bảo số là số, không phải chuỗi chứa số.

Với crawler đẩy dữ liệu hàng loạt

Kiểm dữ liệu ở phía crawler trước khi gửi, bằng schema giống schema của API. Thư viện như Pydantic hay jsonschema giúp kiểm cục bộ, bắt lỗi trước khi tốn request. Bản ghi không qua kiểm cục bộ đưa vào hàng lỗi để xem lại, không gửi.

Tách lỗi 422 khỏi vòng thử lại. Bản ghi nhận 422 đưa thẳng vào hàng lỗi kèm mảng errors. Vòng thử lại chỉ áp cho 429, 5xx và lỗi mạng.

Khi gửi qua proxy, giữ nguyên logic này. Proxy không thay đổi cách xử lý 422. Nếu thấy tỷ lệ 422 thay đổi khi đổi proxy, kiểm xem có phải API trả nội dung khác theo vùng, ví dụ danh sách sku hay country hợp lệ khác theo quốc gia của IP.

Với crawler: đo tỷ lệ 422 theo lô

Đặt ngưỡng tỷ lệ 422 cho mỗi lô, ví dụ 2%. Vượt ngưỡng thì dừng lô và kiểm bước chuyển đổi dữ liệu, vì nhiều khả năng có thay đổi ở nguồn: trang đích đổi định dạng giá, đổi cách ghi ngày, thêm ký tự lạ vào trường số. Tiếp tục gửi chỉ tạo thêm lỗi.

Tỷ lệ 422 đột ngột tăng sau khi đổi proxy sang vùng khác là dấu hiệu dữ liệu cào về đã khác theo vùng, ví dụ đơn vị tiền tệ hay định dạng số thập phân. Lỗi vẫn ở dữ liệu, nhưng nguyên nhân gốc là vùng của proxy. Đây là trường hợp duy nhất đổi proxy có liên quan tới 422.

Kiểm schema cục bộ bằng thư viện

Thư viện jsonschema cho Python kiểm một đối tượng theo tệp schema JSON. Nếu API công bố schema dạng OpenAPI, có thể trích phần schema của request và dùng thẳng. Lỗi trả về cũng có đường dẫn trường và thông báo, gần giống mảng errors của API.

Kiểm cục bộ không thay được kiểm của máy chủ, vì máy chủ còn kiểm các quy tắc cần dữ liệu riêng như sku có tồn tại không. Nhưng nó bắt hết lỗi kiểu, lỗi định dạng và lỗi khoảng giá trị trước khi tốn request.

Lưu bản ghi lỗi để xử lý lại

Bản ghi nhận 422 nên lưu cùng payload gốc và mảng errors vào một bảng riêng. Sau khi sửa bước chuyển đổi, chạy lại các bản ghi trong bảng này, không cần cào lại từ đầu. Đánh dấu bản ghi đã gửi thành công để không gửi trùng.

Với người làm API

Trả mọi lỗi trong một lần, đặt mã code ổn định, theo định dạng problem details. Phân biệt rõ 400, 415 và 422 để client biết sửa ở đâu. Không trả 422 cho lỗi xác thực hay giới hạn tần suất.

Theo dõi theo phiên bản API

API thay đổi quy tắc kiểm theo thời gian: thêm trường bắt buộc, siết định dạng, đổi danh sách giá trị cho phép. Một tool chạy ổn nhiều tháng có thể đột ngột gặp 422 hàng loạt sau khi API cập nhật. Theo dõi trang thay đổi của API và ghi phiên bản API trong log giúp nhận ra nhanh nguyên nhân này.

Khi API có tham số chọn phiên bản, cố định phiên bản trong mã thay vì dùng mặc định. Như vậy thay đổi quy tắc không ảnh hưởng tới tool cho tới khi anh em chủ động nâng cấp.

Giới hạn suy luận của bài

API trong lab tự viết, theo một cách đặt errors cụ thể. API thật có cấu trúc riêng. Proxy lab là proxy HTTP thường, không có lớp kiểm nội dung. Một số proxy bảo mật hay tường lửa ứng dụng có thể chặn request theo nội dung và trả mã riêng, lab không thử.

Lab chỉ kiểm HTTP thường tới máy chủ cục bộ. Với HTTPS qua proxy, proxy càng không thấy nội dung, kết luận vẫn giữ nguyên.

Checklist lỗi 422 Unprocessable Content

• Đọc mã: 415 là kiểu nội dung, 400 là cú pháp, 422 là giá trị.
• Đọc toàn bộ thân phản hồi, tìm mảng errors hoặc trường tương đương.
• Sửa theo field và code, không theo message.
• Dùng tham số json của thư viện, không ghép chuỗi JSON tay.
• Ép kiểu số, ngày, boolean trước khi gửi.
• Kiểm schema cục bộ trước khi gửi hàng loạt.
• Không đưa 422 vào vòng thử lại.
• Không đổi proxy để sửa 422, trừ khi API cho dữ liệu hợp lệ khác theo vùng.

Proxy chỉ giúp phần đường đi và IP, còn dữ liệu đúng là việc của script. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy tốc độ cao tại trang chủ ProxyVN cho phần gọi API cần IP ổn định.

Câu hỏi thường gặp về lỗi 422 Unprocessable Content

Đổi IP có làm hết lỗi 422 không?

Không, trừ khi API áp quy tắc dữ liệu khác theo vùng. 422 phản ánh nội dung request, không phản ánh IP.

Vì sao cùng payload lúc 422 lúc không?

Có thể dữ liệu tham chiếu trên máy chủ thay đổi, ví dụ sku vừa bị xóa, hoặc giá trị phụ thuộc thời gian như ngày giao hàng đã qua. Đọc errors để biết trường nào.

422 có tính vào giới hạn tần suất không?

Thường có. Mỗi request đều tính, kể cả request lỗi. Gửi hàng loạt dữ liệu sai vừa tốn quota vừa có thể kích hoạt chặn.

Lỗi 422 có làm tài khoản bị khóa không?

Một vài lần thì không. Gửi hàng nghìn request sai liên tục có thể bị hệ thống chống lạm dụng coi là bất thường, dẫn tới 429 hay khóa tạm. Dừng lô khi tỷ lệ 422 cao là cách tránh.

API trả 400 cho lỗi dữ liệu thì sao?

Đọc thân phản hồi như với 422. Nhiều API dùng 400 cho mọi lỗi phía client, thân phản hồi mới cho biết lỗi cú pháp hay lỗi giá trị.

FastAPI trả 422 cho lỗi gì?

FastAPI mặc định trả 422 khi dữ liệu request không khớp mô hình Pydantic, kể cả khi thiếu trường bắt buộc. Thân phản hồi có trường detail là danh sách lỗi, mỗi lỗi có loc là đường dẫn trường. Cách đọc giống mảng errors trong lab.

422 có giống lỗi xác thực không?

Không. Thiếu hay sai khóa API cho 401, thiếu quyền cho 403, proxy cần xác thực cho 407. 422 chỉ nói về dữ liệu trong request đã được chấp nhận về mặt quyền.

Có nên tự động sửa dữ liệu theo errors?

Chỉ với lỗi có cách sửa rõ, như ép kiểu chuỗi sang số. Lỗi như sku không tồn tại cần người xem, tự động sửa dễ tạo dữ liệu sai.

Lỗi 422 Unprocessable Content và những điều cần nhớ

Lỗi 422 Unprocessable Content báo dữ liệu đọc được nhưng không hợp lệ, và đi qua proxy y nguyên như đi thẳng. Lab gửi năm payload, cho đúng 201, hai lần 422, 400 và 415, qua proxy không khác một ký tự. Đọc mảng errors, sửa theo field và code, kiểm schema trước khi gửi. Cần proxy ổn định cho phần gọi API khi đã xử lý xong lỗi 422 Unprocessable Content, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.