Nếu không có kết quả thì có thể là một lỗi trong phản hồi RESTful?

Tôi sẽ mô tả một ví dụ:
Tôi bắt đầu tạo API cho cửa hàng bánh. API sẽ cho phép mọi người tìm kiếm danh mục sản phẩm làm bánh của họ, chẳng hạn như bánh quy sô cô la bạc hà làm tại nhà bằng cách sử dụng api.examplebakery.com/search?q=......

Ai đó sử dụng điều này để tìm kiếm một sản phẩm có tên pineapple-banana flavoured cookiesvà rõ ràng sẽ không tìm thấy bất kỳ kết quả nào.

Điều này có nên được trả lại như là một lỗi? Tìm kiếm không thất bại, API đã tìm kiếm và kết luận thành công không tìm thấy cookie nào. API không nên trả về 404, vì API thực sự đã được tìm thấy.

Khi có kết quả, đầu ra là một danh sách (JSON, dựa trên nhận xét của bạn). Đối với các truy vấn không có kết quả, đầu ra phải giống hệt nhau. Danh sách đơn giản có 0 mục trong đó.

Vì vậy, nếu phản hồi của bạn là bình thường này:

{
    "results": [
        {
            "name": "Pancakes",
            ....
        },
        {
            "name": "French Fries",
            ....
        }
    ]
}

Sau đó, đối với một truy vấn có 0 kết quả, nó sẽ là:

{
    "results": []
}

Nếu bạn cũng bao gồm dữ liệu meta về số lượng "trang" kết quả, liên kết đến các "trang" đó, v.v. thì tôi sẽ đề nghị nói có 1 "trang".

Trạng thái HTTP phải giống như khi có kết quả - 200 OK.

204 No Contentcó vẻ cũng là một lựa chọn, nhưng không phải vì bạn thực sự đang trả lại "nội dung" - danh sách trống. Nếu bạn cảm thấy một danh sách trống không được tính là "nội dung", nếu sau đó bạn sửa đổi phản hồi để đưa ra đề xuất chính tả thì sao? Cốt lõi của phản hồi vẫn sẽ là một danh sách trống, nhưng bây giờ thậm chí còn có nhiều "nội dung" hơn.

Để biết thêm thông tin hữu ích về mã trạng thái HTTP, jpmc26 câu trả lời của họ rất đáng đọc.

Bất cứ khi nào quyết định mã HTTP, bạn nên luôn đặt câu hỏi này:

Bất kỳ khách hàng tùy ý có thể / sẽ / nên làm gì với phản hồi?

1. Khách hàng có nên luôn coi phản ứng là một thất bại? Sau đó, bạn muốn 4xx hoặc 5xx, tùy thuộc vào vấn đề là đầu vào của máy khách hay quy trình của máy chủ.
2. Thay vào đó, khách hàng có nên đưa ra yêu cầu ở nơi khác không? Sau đó, 3xx là dành cho bạn.
3. Máy chủ đã làm những gì khách hàng yêu cầu (đã thành công)? Đó là 2xx.

Luôn luôn quyết định phạm vi mã phản hồi của bạn nên ở đầu tiên. Làm như vậy nhanh chóng loại bỏ rất nhiều mã phản hồi dưới dạng tùy chọn và (có thể quan trọng hơn) nó làm cho việc tuân theo ngữ nghĩa của mã đơn giản hơn nhiều. Xem các phần đầu của tài liệu mã HTTP để biết giải thích về từng loại mã thể hiện.

Trong trường hợp này, khách hàng yêu cầu danh sách kết quả được cung cấp bộ lọc từ điểm cuối hợp lệ, hiện có và có quyền truy cập vào nó. Máy chủ đã có thể xử lý yêu cầu và xác định dữ liệu phù hợp để trả về (không có mục nào), vì vậy yêu cầu đã thành công. Nó chỉ xảy ra rằng bộ lọc họ đã lọc ra tất cả các kết quả. Máy chủ không xác định liệu đây có phải là điều khách hàng muốn hay không, vì đây có thể là kết quả mong đợi đối với một số khách hàng. Nếu đó là một vấn đề nào đó đối với mã máy khách, đó là trách nhiệm của khách hàng trong việc xác định, kiểm tra và xử lý một cách thích hợp. Vì vậy, đây rõ ràng là 2xx.

Bây giờ câu hỏi là "2xx nào?" Điều này phụ thuộc vào cách bạn dự định cho máy chủ phản hồi.

• Bạn sẽ gửi lại một đại diện của một danh sách trống, giống như một số câu trả lời khác mô tả? Nếu vậy, bạn muốn 200. 200 có nghĩa là máy chủ không gặp vấn đề gì và có đại diện cho kết quả để khách hàng tiêu thụ. Đây có thể là cách thuận tiện nhất để trả lời cho người tiêu dùng của bạn, người chỉ có thể phân tích phản hồi cho dù có kết quả hay không và sau đó tìm ra cách tự xử lý một danh sách trống.
• 204 không sai về mặt ngữ nghĩa ở đây, nhưng bạn sẽ phải trả lời mà không có thông điệp gì . Điều này có nghĩa là tất cả các mã máy khách sẽ phải kiểm tra rõ ràng các mã HTTP khác nhau (hoặc ít nhất là thiếu phần thân thông báo) và xử lý chúng một cách riêng biệt. Nó bất tiện và có nhiều khả năng dẫn đến các khách hàng cư xử kém.

Những cái khác hoàn toàn không áp dụng:

• 201 là ra khỏi câu hỏi. Bạn đã không tạo bất kỳ tài nguyên liên tục nào và không trả lại vị trí cho tài nguyên đã tạo.
• 202 là ra khỏi câu hỏi. Yêu cầu được thực hiện; nó không xử lý ở chế độ nền.
• 203 có nghĩa là phản hồi đã được sửa đổi giữa máy chủ có thẩm quyền và máy khách. Giao diện RESTful của bạn là máy chủ có thẩm quyền, vì vậy điều này không áp dụng ở đây.
• 205 không có ý nghĩa. Bạn không cần khách hàng xóa hoặc làm mới bất cứ điều gì.
• 206 dường như được thiết kế để trả về một tài nguyên lớn qua nhiều phản hồi. Nó cũng yêu cầu khách hàng yêu cầu một phần nội dung trong các tiêu đề (vì vậy phân trang qua chuỗi truy vấn không đủ điều kiện). Không áp dụng ở đây.

Vì vậy, nó phải là 200 hoặc 204, và 200 có nhiều khả năng dẫn đến mã máy khách đơn giản hơn, mạnh mẽ hơn (đặc biệt nếu bạn sử dụng cấu trúc phản hồi nhất quán có chứa danh sách trống).

Không. Việc sử dụng 404 để chỉ ra 'truy vấn của bạn đã được xử lý nhưng không có kết quả trùng khớp' là khủng khiếp vì:

• luồng có điều kiện dựa trên xử lý ngoại lệ (nghĩa là buộc một kết quả không đặc biệt để tạo và xử lý một ngoại lệ trong máy khách có thể không hiệu quả và khó xử)

• Không rõ ràng giữa trang 'thực', bạn đã nhập sai điểm cuối

Điều cần nhớ là luôn có một khách hàng để giải trừ thông điệp và những gì khách hàng trả lại là điều quan trọng; không phải là tuần tự hóa.

Nếu máy khách sẽ trả về null, sau đó sử dụng tuần tự hóa null. Nếu máy khách sẽ trả về một mảng trống, hãy sử dụng [], nếu máy khách sẽ ném lỗi, hãy sử dụng 500 và truyền thông báo lỗi

Ngoài câu trả lời rất hay của @ Ewan:

Nếu truy vấn là loại trả về một tập hợp kết quả, thì tập hợp trống sẽ hợp lý như một tập hợp của một hoặc một tập hợp nhiều hơn. Nói chung vì những lý do mà @Ewan tuyên bố, việc thay đổi tập hợp trống thành một lỗi có hại, và đơn giản là không cần thiết.

Nếu truy vấn là loại tìm kiếm và trả về một singleton cụ thể (dự kiến ​​sẽ được tìm thấy, ví dụ: khớp chính xác theo id), thì không tìm thấy là một phản ứng phù hợp về mặt logic.

Bạn đang giả sử mã phải thực hiện một hành động đặc biệt khi không có dữ liệu nào được trả về, nhưng đó có thể không phải là trường hợp. Mã có thể chỉ đơn giản là tìm kiếm số lượng sản phẩm hoặc nối thêm kết quả vào danh sách hoặc bất kỳ số lượng nào. Bạn chỉ nên cung cấp cho người dùng một "lỗi" nếu thực sự có lỗi.

Khi tôi sử dụng API, với tư cách là khách hàng, tôi phải xử lý các trường hợp "thành công" khác với các trường hợp "lỗi"; Tôi không có lựa chọn nào ở đó. Do đó, bạn nên trả lại lỗi trong các tình huống mà khách hàng muốn đối xử khác nhau và thành công trong các tình huống mà khách hàng muốn đối xử như nhau.

Nếu tôi thực hiện một truy vấn về lý thuyết có thể trả về bất kỳ số lượng kết quả nào, 0, 1, 2 trăm, thì bạn sẽ trả về "thành công" bất cứ khi nào API cung cấp danh sách đầy đủ tất cả các kết quả. Và có thể trong trường hợp có nhiều kết quả, bạn đã trả về một danh sách một phần kết quả để tránh kích thước quá mức và có một cách đồng ý làm thế nào tôi có thể nhận được kết quả khác. Đó là bởi vì là một khách hàng, tôi thường muốn xử lý trường hợp không có kết quả như trường hợp có nhiều kết quả hơn. Tôi có thể đối xử với nó khác nhau, nhưng tôi không muốn bị ép buộc.

Nó là khác nhau trong trường hợp tôi tìm kiếm một giá trị. Tôi mong đợi chính xác một kết quả, giá trị mà tôi đang tìm kiếm. Và tôi cần một kết quả đó để tiếp tục những gì tôi muốn làm một cách có ý nghĩa. Ở đây, việc trả lại trạng thái 404 cho trường hợp không có giá trị là điều dễ chấp nhận hơn, vì dù sao tôi cũng cần xử lý trường hợp đó một cách khác.

Tóm tắt: Nếu khách hàng mong đợi bất kỳ số lượng kết quả nào, từ số 0 đến số lớn, sau đó trả về "thành công" nếu tất cả các kết quả được gửi, ngay cả khi số đó bằng không. Nếu khách hàng mong đợi chính xác một kết quả, thì trả về thành công nếu kết quả được tìm thấy và một lỗi nếu không tìm thấy kết quả.