Tôi nên sử dụng mã phản hồi trạng thái HTTP nào nếu yêu cầu thiếu tham số bắt buộc?

Tôi đang suy nghĩ 412 (Điều kiện tiên quyết thất bại) nhưng có thể có một tiêu chuẩn tốt hơn?

Tình trạng 422 có vẻ phù hợp nhất dựa trên thông số kỹ thuật .

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.

Họ tuyên bố rằng xml không đúng định dạng là một ví dụ về cú pháp sai (gọi 400). Một chuỗi truy vấn không đúng định dạng có vẻ tương tự như vậy, vì vậy 400 không phù hợp với chuỗi truy vấn được định dạng tốt mà thiếu tham số.

CẬP NHẬT @DavidV chỉ ra một cách chính xác rằng thông số này dành cho WebDAV, không phải HTTP lõi. Nhưng một số API không phải WebDAV phổ biến dù sao cũng đang sử dụng 422, vì thiếu mã trạng thái tốt hơn ( xem phần này ).

Tôi không chắc chắn có một tiêu chuẩn được thiết lập, nhưng tôi đã sử dụng 400 Yêu cầu xấu , tài liệu HTTP mới nhất (từ 2014) như sau :

6.5.1. 400 yêu cầu xấu

Mã trạng thái 400 (Yêu cầu xấu) chỉ ra rằng máy chủ không thể hoặc sẽ không xử lý yêu cầu do lỗi được coi là lỗi máy khách (ví dụ: cú pháp yêu cầu không đúng định dạng, đóng khung thông báo yêu cầu không hợp lệ hoặc định tuyến yêu cầu lừa đảo).

Các API WCF trong tay cầm NET thiếu các thông số bằng cách trả lại một HTTP 404lỗi "Endpoint Not Found", khi sử dụng webHttpBinding .

Điều này 404 Not Foundcó thể có ý nghĩa nếu bạn xem xét tên phương thức dịch vụ web của mình cùng với chữ ký tham số của nó. Đó là, nếu bạn đưa ra một phương thức dịch vụ web LoginUser(string, string)và bạn yêu cầu LoginUser(string), thì cái sau không được tìm thấy.

Về cơ bản, điều này có nghĩa là không thể tìm thấy phương thức dịch vụ web mà bạn đang gọi, cùng với chữ ký tham số bạn đã chỉ định.

10.4.5 404 Không tìm thấy

Máy chủ không tìm thấy bất cứ thứ gì khớp với URI yêu cầu. Không có dấu hiệu nào được đưa ra cho dù điều kiện là tạm thời hay vĩnh viễn.

Như 400 Bad Request, Gert gợi ý , vẫn còn là một mã phản hồi có giá trị, nhưng tôi nghĩ rằng nó thường được sử dụng để chỉ ra các vấn đề cấp dưới. Nó có thể dễ dàng được hiểu là một yêu cầu HTTP không đúng định dạng, có thể thiếu các tiêu đề HTTP không hợp lệ hoặc không hợp lệ hoặc tương tự.

10.4.1 400 Yêu cầu xấu

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.

Bạn có thể gửi 400 mã Yêu cầu xấu. Đây là một trong những mã trạng thái 4xx có mục đích chung hơn, vì vậy bạn có thể sử dụng nó để hiểu ý bạn: khách hàng đang gửi yêu cầu thiếu thông tin / tham số mà ứng dụng của bạn yêu cầu để xử lý chính xác.

Trong một trong các dự án API của chúng tôi, chúng tôi quyết định đặt Trạng thái 409 cho một số yêu cầu, khi chúng tôi không thể điền đầy đủ 100% vì thiếu tham số.

Mã trạng thái HTTP "Xung đột 409" là một thử thách tốt vì định nghĩa của nó đòi hỏi phải bao gồm đủ thông tin để người dùng nhận ra nguồn gốc của xung đột.

Tham khảo: w3.org/Prot Protocol /

Vì vậy, trong số các phản hồi khác như 400 hoặc 404, chúng tôi đã chọn 409 để thực thi nhu cầu xem qua một số ghi chú trong yêu cầu hữu ích để thiết lập một yêu cầu mới và đúng.

Dù trường hợp của chúng tôi là trường hợp cụ thể vì chúng tôi cần gửi một số dữ liệu vào đêm trước nếu yêu cầu không hoàn toàn chính xác và chúng tôi cần buộc khách hàng xem tin nhắn và hiểu những gì sai trong yêu cầu.

Nói chung, nếu chúng ta chỉ có một số tham số bị thiếu, chúng ta sẽ tìm một 400 và một mảng các tham số bị thiếu. Nhưng khi chúng tôi cần gửi thêm một số thông tin, như một thông báo trường hợp cụ thể và chúng tôi muốn chắc chắn hơn rằng khách hàng sẽ chăm sóc nó, chúng tôi sẽ gửi 409

Tôi thường sử dụng 422 (Thực thể không thể xử lý) nếu có gì đó trong các tham số bắt buộc không khớp với điểm cuối API yêu cầu (như mật khẩu quá ngắn) nhưng đối với tham số bị thiếu, tôi sẽ sử dụng 406 (Không thể chấp nhận).

Đối với những người quan tâm, Spring MVC (ít nhất là 3.x) trả về 400 trong trường hợp này, điều này có vẻ sai đối với tôi.

Tôi đã kiểm tra một số URL của Google (Tài khoản.google.com) và đã xóa các tham số bắt buộc và chúng thường trả về 404 trong trường hợp này.

Tôi sẽ sao chép Google.

Có thể lập luận rằng 404 Not Foundnên sử dụng một tài nguyên do không thể tìm thấy tài nguyên được chỉ định.

Tôi thường sử dụng một lỗi 403 Cấm. Lý do là yêu cầu đã được hiểu, nhưng tôi sẽ không làm như yêu cầu (vì mọi thứ đều sai). Thực thể phản hồi giải thích điều gì sai, vì vậy nếu phản hồi là trang HTML, thông báo lỗi nằm trong trang. Nếu đó là phản hồi JSON hoặc XML, thông tin lỗi sẽ nằm ở đó.

Từ rfc2616 :

10,4,4 403 Cấm

Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện nó.
Ủy quyền sẽ không giúp đỡ và yêu cầu KHÔNG NÊN lặp lại.
Nếu phương thức yêu cầu không phải là CHÍNH và máy chủ muốn
công khai lý do tại sao yêu cầu chưa được thực hiện, thì NÊN mô tả lý do từ chối trong thực thể. Nếu máy chủ không muốn cung cấp thông tin này cho khách hàng, mã trạng thái 404
(Không tìm thấy) có thể được sử dụng thay thế.

Chỉ cần sử dụng ASP.NET Core làm tài liệu tham khảo hoặc ví dụ, ASP.NET Core cho phép bạn tạo ra một bộ điều khiển bằng các hành động, đây là cách hành động "Chi tiết" trông như thế nào.

    // GET: Cars/Details/5
    public async Task<IActionResult> Details(int? id)
    {
        if (id == null)
        {
            return NotFound();
        }

        var car = await _context.Cars.FirstOrDefaultAsync(m => m.CarId == id);
        if (car == null)
        {
            return NotFound();
        }

        return View(car);
    }

Nếu tham số idkhông được đặt, thì nó trả về 404 Không tìm thấy.

Trả lại 404 - có nghĩa là không thể tìm thấy tài nguyên.

Hãy thử chỉnh sửa một url của một trang web có chứa một id. Tôi đã thử một vài:

• vấn đề repo gitub
• trang hợp lưu
• xem sản phẩm của amazon
• danh sách ebay
• bài viết tin tức bbc

Tất cả trả về 404, imo vì các nhà phát triển đó đang giải thích chính xác tiêu chuẩn, mà câu trả lời ở đây và nhiều người khác, không phải vậy!

Tôi sẽ đi với một 403.

Từ RFC 2616 - Giao thức truyền siêu văn bản - HTTP / 1.1

403 Cấm

Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện nó. Ủy quyền sẽ không giúp đỡ và yêu cầu KHÔNG NÊN lặp lại. Nếu phương thức yêu cầu không phải là CHÍNH và máy chủ muốn công khai lý do tại sao yêu cầu chưa được thực hiện, thì NÊN mô tả lý do từ chối trong thực thể. Nếu máy chủ không muốn cung cấp thông tin này cho khách hàng, mã trạng thái 404 (Không tìm thấy) có thể được sử dụng thay thế.

Bạn nên mô tả lý do thất bại trong phản ứng của bạn. Nếu bạn không muốn làm điều đó, chỉ cần sử dụng 404.