Giả sử bạn muốn nhận danh sách người dùng bằng cách gọi GET
đến api/users
, nhưng hiện tại bảng đã bị cắt bớt nên không có người dùng. Phản ứng thích hợp cho tình huống này là gì: 404
hoặc 204
?
/api/users
trong khi câu đó là về /api/users/1
.
Giả sử bạn muốn nhận danh sách người dùng bằng cách gọi GET
đến api/users
, nhưng hiện tại bảng đã bị cắt bớt nên không có người dùng. Phản ứng thích hợp cho tình huống này là gì: 404
hoặc 204
?
/api/users
trong khi câu đó là về /api/users/1
.
Câu trả lời:
Tôi cũng không muốn nói.
Mã trạng thái 404 nên được dành riêng cho các trường hợp không tìm thấy tài nguyên. Trong trường hợp này, tài nguyên của bạn là một tập hợp người dùng . Bộ sưu tập này tồn tại nhưng nó hiện đang trống. Cá nhân tôi, tôi sẽ rất bối rối với tư cách là tác giả của một ứng dụng khách cho ứng dụng của bạn nếu tôi nhận được một 200
ngày và một 404
ngày hôm sau chỉ vì ai đó tình cờ xóa một vài người dùng. Tôi phải làm gì bây giờ? URL của tôi có sai không? Có ai đó đã thay đổi API và bỏ qua việc chuyển hướng không.
Đây là một đoạn trích từ mô tả của mã trạng thái 204 của w3c
Máy chủ đã hoàn thành yêu cầu nhưng không cần trả lại phần thân thực thể và có thể muốn trả về thông tin cập nhật.
Mặc dù điều này có vẻ hợp lý trong trường hợp này, nhưng tôi nghĩ nó cũng sẽ khiến khách hàng bối rối. A 204
được cho là chỉ ra rằng một số hoạt động đã được thực hiện thành công và không cần trả lại dữ liệu nào. Đây là một phản hồi hoàn hảo cho một DELETE
yêu cầu hoặc có thể kích hoạt một số tập lệnh không cần trả lại dữ liệu. Trong trường hợp này api/users
, bạn thường mong đợi nhận được bản trình bày về tập hợp người dùng của mình. Việc gửi nội dung phản hồi một lần và không gửi lần khác là không nhất quán và có khả năng gây hiểu lầm.
Vì những lý do đã đề cập ở trên (tính nhất quán), tôi sẽ trả về một đại diện của một tập hợp rỗng. Giả sử bạn đang sử dụng XML. Nội dung phản hồi bình thường cho một tập hợp người dùng không trống có thể trông giống như sau:
<users>
<user>
<id>1</id>
<name>Tom</name>
</user>
<user>
<id>2</id>
<name>IMB</name>
</user>
</users>
và nếu danh sách trống, bạn chỉ có thể trả lời như sau (trong khi vẫn sử dụng a 200
):
<users/>
Dù bằng cách nào, khách hàng sẽ nhận được nội dung phản hồi tuân theo một định dạng nhất định, nổi tiếng. Không có sự nhầm lẫn không cần thiết và kiểm tra mã trạng thái. Ngoài ra, không có định nghĩa mã trạng thái nào bị vi phạm. Mọi người đều vui vẻ.
Bạn có thể làm tương tự với JSON hoặc HTML hoặc bất kỳ định dạng nào bạn đang sử dụng.
[]
.
GET /singleCoin
- trả lại một đồng xu ngẫu nhiên từ túi của bạn, GET /severalCoins
- trả lại một số đồng từ túi mà bạn có thể lấy trong một lần. Giả sử bạn không có xu nào trong túi hiện tại. Khi bạn yêu cầu GET /singleCoin
bạn sẽ nhận được 404 Not Found
, nhưng khi bạn yêu cầu, GET /severalCoins
bạn sẽ nhận được 200 OK
với danh sách trống []
. Một sự thật - bạn không có đồng xu nào, được mô tả với những phản hồi khác nhau, tại sao? Tôi nên nói rằng tốt hơn hết là nên lấy 404 Not Found
, bởi vì không có đồng xu nào được tìm thấy trong túi của bạn.
GET /severalCoins
. Nếu bạn bắt buộc GET /severalCoins
phải trả lại một số đồng xu thì nó không nên là 200 vì nó không ổn; máy chủ không thể cung cấp những gì khách hàng muốn. Đối với /singleCoin
điều này là hiển nhiên bởi vì khách hàng muốn chính xác một đồng xu, không hơn không kém. Điều này là tương tự cho /coins/7
. Ngược lại đối với /coins
điểm cuối, khách hàng thường không mong đợi một đồng tiền, một đồng hoặc nhiều đồng. Tất cả chúng đều là phản hồi hợp lệ. Nếu không có đồng xu, thì đây là những gì họ muốn. Nó giống như một emply List<Coin>
trong Java, thay vì null
.
Tôi sẽ trả lời một trong hai mã tùy thuộc vào tình huống thời gian chạy:
404 không tìm thấy)
Câu trả lời này là khá chính xác nếu bạn không có bảng. Không chỉ là bảng trống mà KHÔNG CÓ BẢNG NGƯỜI DÙNG. Nó xác nhận ý tưởng chính xác - không có tài nguyên. Các tùy chọn khác là cung cấp thêm thông tin chi tiết TẠI SAO bảng của bạn không có, có một vài mã chi tiết hơn nhưng 404 khá tốt để đề cập đến trường hợp bạn thực sự không có bảng.
200 (Được)
Tất cả các trường hợp bạn có bảng nhưng nó trống hoặc bộ xử lý yêu cầu của bạn đã lọc ra tất cả các kết quả. Điều này có nghĩa là 'yêu cầu của bạn là đúng, mọi thứ đều ổn nhưng bạn không khớp với bất kỳ dữ liệu nào chỉ vì chúng tôi không có dữ liệu hoặc chúng tôi không có dữ liệu nào phù hợp với yêu cầu của bạn. Điều này sẽ khác với câu trả lời từ chối bảo mật. Tôi cũng bỏ phiếu trả lại 200 trong trường hợp bạn có một số dữ liệu và nói chung bạn được phép truy cập vào bảng nhưng không có quyền truy cập vào tất cả dữ liệu phù hợp với yêu cầu của bạn (dữ liệu đã được lọc ra vì bảo mật cấp đối tượng nhưng nói chung bạn được phép yêu cầu).
404 có nghĩa là không tìm thấy tài nguyên. Nhưng tài nguyên tồn tại. Ngoài ra, nếu phản hồi có trạng thái 404. Làm thế nào bạn có thể biết danh sách người dùng trống hoặc đầy?