Mã trạng thái HTTP bên phải để nhập sai

Mã phản hồi HTTP tối ưu là gì khi không báo cáo 200 (mọi thứ đều ổn) nhưng lỗi trong đầu vào là gì?

Giống như, bạn gửi một số dữ liệu đến máy chủ và nó sẽ phản hồi rằng dữ liệu của bạn sai

sử dụng 500trông giống như Sự cố máy chủ
sử dụng 200với văn bản phản hồi cảnh báo / lỗi là xấu (cho phép lưu vào bộ nhớ cache và mọi thứ không ổn)
sử dụng 204và không trả về gì, có thể tốt (nhưng được hỗ trợ tốt?)
sử dụng 404sai nếu đường dẫn được yêu cầu (tập lệnh) có sẵn và ở nơi thích hợp

Chúng tôi cũng gặp vấn đề tương tự khi tạo API của mình. Chúng tôi đang tìm kiếm một mã trạng thái HTTP tương đương với một InvalidArgumentException. Sau khi đọc bài viết nguồn dưới đây, chúng tôi đã kết thúc bằng cách sử dụng 422 Unprocessable Entitycác trạng thái:

Mã trạng thái 422 (Thực thể không thể xử lý) có nghĩa là máy chủ hiểu loại nội dung của thực thể yêu cầu (do đó mã trạng thái 415 (Loại phương tiện không được hỗ trợ) là không phù hợp) và cú pháp của thực thể yêu cầu là chính xác (do đó là 400 (Yêu cầu sai ) mã trạng thái không phù hợp) nhưng không thể xử lý các hướng dẫn có trong đó. Ví dụ, điều kiện lỗi này có thể xảy ra nếu một thân yêu cầu XML chứa các hướng dẫn XML được định dạng đúng (nghĩa là đúng về mặt cú pháp), nhưng sai về mặt ngữ nghĩa, về mặt ngữ nghĩa.

nguồn: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

Mã bắt đầu bằng 4 (4xx) có nghĩa là lỗi máy khách. Có lẽ 400 (Yêu cầu xấu) có thể phù hợp với trường hợp này? Định nghĩa trong http://www.w3.org/Prot Protocol / rfc2616 / rfc2616-sec10.html nói:

"Máy chủ không thể hiểu được yêu cầu do cú pháp không đúng. Máy khách KHÔNG NÊN lặp lại yêu cầu mà không sửa đổi."

Ngoài RFC Spec, bạn cũng có thể thấy điều này trong thực tế. Kiểm tra các phản hồi twitter.

https://developer.twitter.com/en/docs/ads/general/guides/response-codes

409 Conflict có thể là một giải pháp chấp nhận được

Theo: https://www.w3.org/Prot Protocol / rfc2616 / rfc2616-sec10.html

Yêu cầu không thể được hoàn thành do xung đột với trạng thái hiện tại của tài nguyên. Mã này chỉ được phép trong các tình huống mà người dùng dự kiến ​​có thể giải quyết xung đột và gửi lại yêu cầu. Cơ quan phản hồi NÊN bao gồm đủ thông tin để người dùng nhận ra nguồn gốc của xung đột. Lý tưởng nhất, thực thể phản hồi sẽ bao gồm đủ thông tin cho người dùng hoặc tác nhân người dùng để khắc phục sự cố; tuy nhiên, điều đó có thể là không thể và không bắt buộc.

Tài liệu tiếp tục với một ví dụ:

Xung đột rất có thể xảy ra để đáp ứng yêu cầu PUT. Ví dụ: nếu phiên bản đang được sử dụng và thực thể là PUT bao gồm các thay đổi đối với tài nguyên xung đột với tài nguyên được tạo bởi yêu cầu trước đó (bên thứ ba), máy chủ có thể sử dụng phản hồi 409 để cho biết rằng nó không thể hoàn thành yêu cầu . Trong trường hợp này, thực thể phản hồi có thể sẽ chứa một danh sách các khác biệt giữa hai phiên bản theo định dạng được xác định bởi Kiểu nội dung phản hồi.

Trong trường hợp của tôi, tôi muốn PUT một chuỗi, phải là duy nhất, cho cơ sở dữ liệu thông qua API. Trước khi thêm nó vào cơ sở dữ liệu, tôi kiểm tra xem nó chưa có trong cơ sở dữ liệu.

Nếu có, tôi sẽ trở lại "Error: The string is already in the database", 409.

Tôi tin rằng đây là những gì OP muốn: một mã lỗi phù hợp khi dữ liệu không vượt qua tiêu chí của máy chủ.

Theo kịch bản dưới đây,

Giả sử ai đó đưa ra yêu cầu đến máy chủ của bạn với dữ liệu ở định dạng chính xác, nhưng đơn giản là dữ liệu "không tốt". Vì vậy, ví dụ, hãy tưởng tượng rằng ai đó đã đăng một giá trị Chuỗi lên điểm cuối API mong đợi giá trị Chuỗi; nhưng, giá trị của chuỗi chứa dữ liệu được liệt kê trong danh sách đen (ví dụ: ngăn mọi người sử dụng "mật khẩu" làm mật khẩu của họ). sau đó mã trạng thái có thể là 400 hoặc 422?

Cho đến bây giờ, tôi đã trả lại "400 Yêu cầu xấu", theo w3.org, có nghĩa là:

Máy chủ không thể hiểu được yêu cầu do cú pháp không đúng. Khách hàng KHÔNG NÊN lặp lại yêu cầu mà không sửa đổi.

Mô tả này không hoàn toàn phù hợp với hoàn cảnh; nhưng, nếu bạn đi theo danh sách mã trạng thái HTTP cốt lõi được xác định trong giao thức HTTP / 1.1, thì đó có lẽ là lựa chọn tốt nhất của bạn.

Tuy nhiên, gần đây, một người nào đó trong nhóm Dev của tôi đã chỉ ra [với tôi] rằng các API phổ biến đang bắt đầu sử dụng các tiện ích mở rộng HTTP để có được chi tiết hơn với báo cáo lỗi của chúng. Cụ thể, nhiều API, như Twitter và Recurly, đang sử dụng mã trạng thái "422 Thực thể không thể xử lý" như được định nghĩa trong tiện ích mở rộng HTTP cho WebDAV. Mã trạng thái HTTP 422 trạng thái:

Mã trạng thái 422 (Thực thể không thể xử lý) có nghĩa là máy chủ hiểu loại nội dung của thực thể yêu cầu (do đó mã trạng thái 415 (Loại phương tiện không được hỗ trợ) là không phù hợp) và cú pháp của thực thể yêu cầu là chính xác (do đó là 400 (Yêu cầu sai ) mã trạng thái không phù hợp) nhưng không thể xử lý các hướng dẫn có trong đó. Ví dụ, điều kiện lỗi này có thể xảy ra nếu một thân yêu cầu XML chứa các hướng dẫn XML được định dạng đúng (nghĩa là đúng về mặt cú pháp), nhưng sai về mặt ngữ nghĩa, về mặt ngữ nghĩa.

Quay trở lại ví dụ mật khẩu của chúng tôi từ phía trên, mã trạng thái 422 này cảm thấy phù hợp hơn nhiều. Máy chủ hiểu những gì bạn đang cố gắng làm; và nó hiểu dữ liệu mà bạn đang gửi; nó chỉ đơn giản là không để dữ liệu đó được xử lý.

404 - Không tìm thấy - có thể được sử dụng cho URI được yêu cầu không hợp lệ hoặc tài nguyên được yêu cầu như người dùng, không tồn tại.