Dịch vụ RESTful, cách trả lời nếu xác thực không thành công?

tôi có dịch vụ đó có một số thực thể và cần phải lưu/cập nhật tổ chức này:Dịch vụ RESTful, cách trả lời nếu xác thực không thành công?

http://myhost.com/rest/entity

tôi sử dụng POST và nộp JSON. Bên trong dịch vụ nó phát hiện rằng thực thể được thông qua là không tốt. Không hợp lệ, đơn đặt hàng được thông qua với khách hàng không tồn tại, v.v.

Tôi nên trả lời như thế nào? HttpCode.NotFound? Hoặc những người khác? Làm thế nào để bạn trả lời những điều như vậy?

Nguồn

2012-01-20 katit

Vâng, điều đó thực sự tùy thuộc vào quyết định của bạn, đó là dịch vụ của bạn. – jgroenen

có thể trùng lặp của [mã trạng thái REST HTTP để xác thực không thành công hoặc trùng lặp không hợp lệ] (http://stackoverflow.com/questions/3290182/rest-http-status-codes-for-failed-validation-or-invalid-duplicate) – MaxiWheat

Trong dự án của chúng tôi trong tình huống như vậy, chúng tôi thực hiện như sau:

Set mã phản hồi HTTP 400 Bad Request
cơ thể Set đáp ứng với JSON sau: {"message":"%extended error message here%"}

Nhưng nó thực sự rất chủ quan.

Ngoài ra tôi khuyên bạn nên đọc This blog article on RESTfull error handling - nó mô tả nhiều tùy chọn có sẵn, vì vậy bạn có thể chọn thứ gì đó cho khẩu vị của mình.

Nguồn

2012-01-20 16:01:00

Đây là những gì chúng ta làm. Chúng tôi trả về cùng loại phương tiện được hỏi nếu có. Trong thế giới web, bạn lấy lại 400 với text \ html. Trong ví dụ này, loại phương tiện là ứng dụng \ json – suing

Cảm ơn bạn! Tôi nghĩ đến việc chuyển một số thông tin vào tiêu đề ngoài mã trạng thái nhưng giữa bài viết bạn đã giới thiệu và bài đăng này tôi nghĩ tôi sẽ quyết định đối tượng phản hồi chung cho dịch vụ của mình và chỉ sử dụng 400 và 200 mã (Khác 401 cho auth) – katit

Tôi nghĩ bạn nên chọn client error code. 400 Bad Request hoặc 403 Forbidden có thể là một khởi đầu tốt

Nguồn

2012-01-20 16:02:23

418 là sự lựa chọn hiển nhiên ở đó. –

403 không phù hợp với kịch bản được mô tả. –

Tại sao 403 không phù hợp? http://stackoverflow.com/a/3290369/59639 Có vẻ như có các trường khác nhau mặc dù trên 400 so với 403 –

422 Unprocessable Entity, defined in WebDAV (RFC 4918):

Các 422 (Không thể xử Entity) mã trạng thái nghĩa là máy chủ hiểu được kiểu nội dung của đối tượng yêu cầu (do đó một 415 Mã trạng thái (Loại phương tiện không được hỗ trợ) không phù hợp) và cú pháp của thực thể yêu cầu là chính xác (do đó mã trạng thái 400 (Yêu cầu không hợp lệ) không phù hợp) nhưng không thể xử lý các hướng dẫn chứa. 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 khuôn dạng được định dạng đúng (nghĩa là cú pháp chính xác), nhưng các câu lệnh XML có ngữ nghĩa sai.

Nguồn

2012-01-20 23:53:42

Tôi thực sự thích điều này. Nó có thể sẽ không được ưa chuộng với những người theo chủ nghĩa thuần túy nhưng tốt hơn là sử dụng cùng một tình trạng như một yêu cầu không đúng định dạng. –

Về dự án tôi đang làm việc trên tôi cũng rất bực mình vì không có khả năng để khách hàng phân biệt giữa các lỗi xác nhận và yêu cầu không đúng định dạng từ mã trạng thái (w/o kiểm tra thân phản hồi), và độc lập nghĩ đến việc sử dụng 422 để phân biệt cái cũ. Tôi đã xem xét điều này trong khi thực hiện một số kiểm tra sanity để đảm bảo không có lựa chọn thay thế tốt hơn, vì vậy tôi vui mừng khi thấy người khác đã sử dụng phương pháp này và điều này không hoàn toàn nằm ngoài cánh đồng.Tôi có thể cho rằng không ai trong số các bạn gặp phải các vấn đề hạ lưu khác với cách tiếp cận này? – rscarter

Dịch vụ RESTful, cách trả lời nếu xác thực không thành công?

Trả lời

Các vấn đề liên quan