Trả lại HTTP 409 có phù hợp để kiểm tra xác thực không?

Question

Tôi có một dịch vụ mà một số quy tắc xác nhận phải được kiểm tra trước khi một hoạt động cụ thể có thể diễn ra.

Ví dụ: khách hàng không được tạo báo cáo có thể in nếu tất cả các quy tắc xác thực không được đáp ứng. Tuy nhiên, một khách hàng cá nhân có thể không có tất cả thông tin cần thiết (người dùng đó chỉ có thể truy cập một tập con dữ liệu được sử dụng để xác định thành công xác thực), vì vậy yêu cầu phải được gửi đến máy chủ: về cơ bản "là một số thing hợp lệ giữa start và finish".

Phản hồi sẽ là một số loại mã thông báo cho biết VALID: FEEL FREE TO CONTINUE hoặc danh sách lý do lỗi xác thực, có thể được trình bày cho người dùng.

Rõ ràng là xác thực thành công sẽ trả về 200 OK. Nhưng tôi không cảm thấy rằng mã trạng thái thành công là thích hợp cho lỗi xác thực. Tôi đang hướng tới một số 409 Conflict, nhưng tôi đã từng sử dụng điều này để từ chối một số PUT hoặc POST. Có hợp lệ (snicker) để có lỗi xác thực được chỉ ra bởi một số 409 hoặc có cách nào tốt hơn không?

Lưu ý: hành động được thực hiện không được thực hiện trên máy chủ, vì vậy bỏ qua kiểm tra này và chỉ thực hiện hành động với 403 trong trường hợp hành động bị cấm không phải là một tùy chọn.

Answer 1

Bạn đã gửi yêu cầu tới máy chủ để máy chủ thực hiện xác thực. Nó đã thực hiện thành công việc xác nhận hợp lệ. Từ góc độ HTTP, yêu cầu được cấu hình tốt và được xử lý chính xác bởi máy chủ.

Vì vậy, tôi muốn nói trả về bất kỳ mã lỗi HTTP nào sẽ không chính xác.

---

Câu trả lời này tiếp tục nhận được phiếu giảm giá và tôi không hoàn toàn chắc chắn lý do tại sao (không có trình gỡ xuống nào có vẻ để lại bất kỳ nhận xét nào). Thông qua một số tiền hợp lý qua lại với OP, chúng tôi đã thiết lập rằng toàn bộ số của yêu cầu/phản hồi này là để thực hiện xác thực. Máy chủ đã nhận được yêu cầu, nó đã thực hiện xác thực rằng nó đã được yêu cầu thực hiện và nó trả về kết quả của quá trình xác nhận đó cho người gọi.

Hoàn toàn không có gì sai khi khách hàng gửi yêu cầu này.

Máy chủ đã hiểu yêu cầu.

Yêu cầu hợp lệ (từ góc độ HTTP).

Máy chủ có thể xử lý yêu cầu.

Máy chủ thực hiện 100% hoạt động mà nó có ý nghĩa và trả lại kết quả được tạo ra khi xử lý yêu cầu.

Và đó là lý do tại sao, như tôi nói, tôi không tin rằng mã lỗi HTTP là thích hợp.

I.e. hãy tưởng tượng rằng máy chủ đưa ra một điểm cuối xác nhận địa chỉ email (cho bất kỳ biểu mẫu cụ thể nào mà bạn muốn nói rằng việc xác thực có thể được thực hiện). Nó nhận được một yêu cầu nói "xác nhận abc@invalid.org" và nó tạo ra một câu trả lời cho biết "Tôi đã xem xét địa chỉ email này và tôi muốn bạn thông báo cho người dùng rằng tôi không thể nhận được phản hồi DNS hợp lệ cho không hợp lệ .org ". Nếu mọi người không nghĩ rằng câu trả lời 200 là chính xác tại đây, tôi muốn yêu thích để hiểu lý do của họ.

Answer 2

Tôi nghĩ rằng miễn là bạn không lạm dụng mã cho một cái gì đó nó không được dự định thì nó thực sự đi xuống đến sở thích và ý kiến. Một 409 có lẽ là ok để sử dụng cho thất bại xác nhận mặc dù tôi nghĩ rằng cá nhân tôi muốn một 200 với lỗi xác nhận như là một phản ứng. Tôi nghĩ điều này giúp các nhà phát triển dễ dàng kiểm tra các lỗi giao tiếp thông thường như 401 hoặc 500 và xử lý chúng trước khi họ phải lo lắng về việc xác thực dữ liệu mà họ đã gửi.

Answer 3

Mặc dù nó được xác định trong tiêu chuẩn được đề xuất, 422 Unprocessable Entity là trạng thái thích hợp.

Các 422 (Không thể xử Entity) mã trạng thái nghĩa là máy chủ hiểu kiểu nội dung của đối tượng yêu cầu (vì thế một 415 (không được hỗ trợ Media Type) mã trạng thái là không phù hợp), và cú pháp của tổ chức yêu cầu đúng (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 có chứa .

Ví dụ: điều kiện lỗi này có thể xảy ra nếu phần nội dung yêu cầu XML chứa các định dạng XML đúng ngữ pháp, có nghĩa là .

Tài liệu tham khảo:

• https://tools.ietf.org/html/rfc4918#section-11.2
• http://developer.github.com/v3/#client-errors
• https://stackoverflow.com/a/2657624/247702
• http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error

Answer 4

Nếu tình trạng tài nguyên HTTP của bạn là ở đâu đó "giữa bắt đầu một thứ hai kết thúc "để diễn giải lời nói của bạn về câu hỏi cũ hơn này, tôi muốn bỏ phiếu cho trạng thái trở về 202. Nó có lợi thế là một phản ứng kiểu 2 -" thành công "để một khách hàng dumber sẽ không xem xét nó trang bị hỏng và mục đích đã nêu trong thông số HTTP 1.1 có vẻ giống như những gì bạn muốn (mặc dù nhiều định nghĩa mã trạng thái rất mơ hồ).

Specification Link

Trích:

202 Accepted 

The request has been accepted for processing, but the processing has not been 
completed. The request might or might not eventually be acted upon, as it 
might be disallowed when processing actually takes place... 

The 202 response is intentionally non-committal. Its purpose is to allow a server 
to accept a request for some other process (perhaps a batch-oriented process 
that is only run once per day) without requiring that the user agent's 
connection to the server persist until the process is completed. The entity 
returned with this response SHOULD include an indication of the request's 
current status and either a pointer to a status monitor or some estimate of 
when the user can expect the request to be fulfilled.