Mã trạng thái HTTP cho một yêu cầu thành công một phần

Tôi có một ứng dụng gửi tin nhắn cho người dùng. Trong một yêu cầu bài đăng, một chuỗi XML được chuyển bao gồm tất cả những người dùng sẽ nhận được thông báo cụ thể đó. Nếu bất kỳ người dùng nào trong danh sách không tồn tại, tôi sẽ cung cấp lại danh sách người dùng bị thiếu cho khách hàng để đánh giá thêm.

Bây giờ tôi đang tự hỏi mình mã trạng thái thích hợp cho ứng dụng nói rằng yêu cầu đã được chấp nhận nhưng có những điều không thể thực hiện được.

Vấn đề sẽ tránh được nếu nó không được phép đưa những người dùng bị thiếu vào danh sách. Sau đó, nỗ lực gửi sẽ chỉ gặp lỗi 4xx. Nhưng chẳng ích gì khi hình thành API theo cách này. Mặt khác, tôi có thể coi điều kiện lỗi hoàn toàn là ứng dụng cụ thể. Nhưng gửi 200 không cảm thấy đúng. Và sẽ rất tuyệt nếu cung cấp cho khách hàng một gợi ý khi nào nên xem xét kỹ phản hồi lỗi. ví dụ: để tránh gửi tin nhắn cho người dùng đó nhiều lần

Tôi đã giải quyết một vấn đề tương tự. Trong trường hợp này, tôi đã trả lại một

207 Đa trạng thái

Bây giờ, đây không phải là HTTP nghiêm ngặt, nó là một phần của tiện ích mở rộng WebDAV, vì vậy nếu bạn cũng không có quyền kiểm soát ứng dụng khách, thì điều này không tốt cho bạn. Nếu bạn làm vậy, bạn có thể làm điều gì đó như sau:

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D='DAV:'>
     <D:response>
       <D:user>user-123</D:user>
       <D:status>success</D:status>
     </D:response>
     <D:response>
       <D:user>user-789</D:user>
       <D:status>failure</D:status>
     </D:response>
   </D:multistatus>

Nhưng một lần nữa, đây là một phần mở rộng HTTP và bạn cũng cần có quyền kiểm soát ứng dụng khách.

Tôi đã gặp vấn đề tương tự và cuối cùng tôi đã sử dụng hai giải pháp khác nhau:

• Mã trả về HTTP 202: Accepted, cho biết rằng yêu cầu đã ổn, nhưng không có gì đảm bảo rằng mọi thứ thực sự diễn ra như bình thường.
• Trả lại bình thường 200trong phản hồi, nhưng bao gồm danh sách những gì không xuất hiện trong nội dung phản hồi.

Cái thứ hai thường hoạt động tốt nhất, nhưng cái đầu tiên là tuyệt vời nếu bạn lười biếng hoặc sử dụng hàng đợi để xử lý.

Còn về việc sử dụng 206 Nội dung một phần. Tôi biết 206 là nhiều hơn về phạm vi, nhưng điều gì sẽ xảy ra nếu nó có thể chỉ ra một yêu cầu thành công một phần?

Giao thức truyền siêu văn bản giải quyết khía cạnh truyền tải của mọi thứ. Nó không có mã lỗi để đối phó với các lỗi cấp ứng dụng.

Trả lại 200 là điều đúng đắn cần làm ở đây. Theo như HTTP có liên quan, yêu cầu đã được nhận đúng cách, được xử lý đúng cách và bạn đang gửi phản hồi trở lại. Vì vậy, ở cấp độ HTTP, mọi thứ đều ổn. Bất kỳ lỗi hoặc cảnh báo nào liên quan đến ứng dụng chạy trên http phải nằm trong phản hồi. Làm như vậy cũng sẽ ngăn chặn một số vấn đề khó chịu mà bạn có thể gặp phải với các máy chủ proxy có thể không xử lý các phản hồi nhất định theo cách bạn mong đợi.