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ệ

Tôi đang xây dựng một ứng dụng với API dựa trên REST và đã đến lúc tôi chỉ định mã trạng thái cho mỗi yêu cầu.

Tôi nên gửi mã trạng thái nào cho các yêu cầu không xác thực hoặc yêu cầu đang cố gắng thêm một bản sao trong cơ sở dữ liệu của tôi?

Tôi đã xem qua http://www.w3.org/Prot Protocol / rfc2616 / rfc2616-sec10.html nhưng không ai trong số họ có vẻ đúng.

Có một thực tế phổ biến khi gửi mã trạng thái?

Đối với lỗi xác thực đầu vào: 400 Yêu cầu xấu + mô tả tùy chọn của bạn. Điều này được đề xuất trong cuốn sách " RESTful Web Services ". Để gửi gấp đôi: 409 Xung đột

Cập nhật tháng 6 năm 2014

Thông số kỹ thuật có liên quan được sử dụng là RFC2616 , cho phép sử dụng 400 (Yêu cầu xấu) khá hẹp như

Máy chủ không thể hiểu được yêu cầu do cú pháp không đúng

Vì vậy, nó có thể đã được lập luận rằng nó không phù hợp cho các lỗi ngữ nghĩa. Nhưng không còn nữa; kể từ tháng 6 năm 2014, RFC 7231 tiêu chuẩn có liên quan , thay thế cho RFC2616 trước đó, cho phép sử dụng rộng rãi hơn 400 (Yêu cầu xấu)

máy chủ không thể hoặc sẽ không xử lý yêu cầu do lỗi được coi là lỗi máy khách

• Xác thực thất bại: 403 Bị cấm ("Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện"). Trái với ý kiến ​​phổ biến, RFC2616 không nói "403 chỉ nhằm mục đích xác thực thất bại", nhưng "403: Tôi biết bạn muốn gì, nhưng tôi sẽ không làm điều đó". Điều kiện đó có thể hoặc không thể do xác thực.
• Cố gắng thêm một bản sao: 409 Xung đột ("Không thể hoàn thành yêu cầu do mâu thuẫn với trạng thái hiện tại của tài nguyên.")

Bạn chắc chắn nên đưa ra lời giải thích chi tiết hơn trong các tiêu đề và / hoặc phần thân phản hồi (ví dụ: với tiêu đề tùy chỉnh - X-Status-Reason: Validation failed).

Tôi đề nghị mã trạng thái 422, "Thực thể không thể xử lý" .

11.2. Thực thể không thể xử lý 422

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

200.300, 400, 500 đều rất chung chung. Nếu bạn muốn chung chung, 400 là OK.

422 được sử dụng bởi số lượng API ngày càng tăng và thậm chí còn được Rails sử dụng ngoài hộp.

Bất kể mã trạng thái nào bạn chọn cho API của mình, ai đó sẽ không đồng ý. Nhưng tôi thích 422 vì tôi nghĩ '400 + trạng thái văn bản' là quá chung chung. Ngoài ra, bạn không tận dụng trình phân tích cú pháp sẵn sàng JSON; ngược lại, một 422 với phản hồi JSON là rất rõ ràng và rất nhiều thông tin lỗi có thể được chuyển tải.

Nói về phản hồi JSON, tôi có xu hướng chuẩn hóa phản hồi lỗi Rails cho trường hợp này, đó là:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

Định dạng này là hoàn hảo để xác thực mẫu, mà tôi cho là trường hợp phức tạp nhất để hỗ trợ về 'mức độ giàu báo cáo lỗi'. Nếu cấu trúc lỗi của bạn là thế này, nó có thể sẽ xử lý tất cả các nhu cầu báo cáo lỗi của bạn.

200

Ugh ... (309, 400, 403, 409, 415, 422) ... rất nhiều câu trả lời cố gắng đoán, tranh luận và chuẩn hóa đâu là mã trả lại tốt nhất cho yêu cầu HTTP thành công nhưng cuộc gọi REST thất bại .

Việc trộn mã trạng thái HTTP và mã trạng thái REST là sai .

Tuy nhiên, tôi đã thấy nhiều triển khai trộn lẫn chúng và nhiều nhà phát triển có thể không đồng ý với tôi.

Mã trả về HTTP có liên quan đến HTTP Requestchính nó. Một cuộc gọi REST được thực hiện bằng cách sử dụng yêu cầu Giao thức truyền siêu văn bản và nó hoạt động ở mức thấp hơn so với chính phương thức REST được gọi. REST là một khái niệm / cách tiếp cận và đầu ra của nó là kết quả kinh doanh / logic , trong khi mã kết quả HTTP là một phương tiện giao thông .

Ví dụ: trả về "404 Không tìm thấy" khi bạn gọi / người dùng / bị nhầm lẫn, bởi vì điều đó có thể có nghĩa là:

• URI sai (HTTP)
• Không tìm thấy người dùng (REST)

"403 Bị cấm / Truy cập bị từ chối" có thể có nghĩa là:

• Cần có sự cho phép đặc biệt Trình duyệt có thể xử lý nó bằng cách hỏi người dùng / mật khẩu. (HTTP)
• Quyền truy cập sai được cấu hình trên máy chủ. (HTTP)
• Bạn cần được xác thực (REST)

Và danh sách có thể tiếp tục với '500 Lỗi máy chủ "(lỗi ném HTTP / Nginx HTTP hoặc lỗi ràng buộc kinh doanh trong REST) ​​hoặc các lỗi HTTP khác, v.v ...

Từ mã, thật khó để hiểu lý do thất bại là gì, lỗi HTTP (vận chuyển) hay lỗi REST (logic).

Nếu yêu cầu HTTP được thực hiện thành công, nó sẽ luôn trả về 200 mã, bất kể (các) bản ghi có được tìm thấy hay không. Bởi vì tài nguyên URI được tìm thấy và được xử lý bởi máy chủ HTTP. Vâng, nó có thể trả về một bộ trống. Có thể nhận được một trang web trống với kết quả 200 như HTTP không?

Thay vì điều này, bạn có thể trả về 200 mã HTTP với một số tùy chọn:

• Đối tượng "lỗi" trong kết quả JSON nếu có lỗi xảy ra
• Mảng / đối tượng JSON trống nếu không tìm thấy bản ghi
• Cờ kết quả / thành công bool kết hợp với các tùy chọn trước đó để xử lý tốt hơn.

Ngoài ra, một số nhà cung cấp internet có thể chặn yêu cầu của bạn và trả lại cho bạn mã HTTP 404. Điều này không có nghĩa là dữ liệu của bạn không được tìm thấy, nhưng có gì đó không đúng ở cấp độ vận chuyển.

Từ Wiki :

Vào tháng 7 năm 2004, nhà cung cấp dịch vụ viễn thông BT Group của Anh đã triển khai hệ thống chặn nội dung Cleanfeed, trả về lỗi 404 cho bất kỳ yêu cầu nào về nội dung được xác định là có thể bất hợp pháp bởi Internet Watch Foundation. Các ISP khác trả về lỗi "cấm" HTTP 403 trong cùng trường hợp. Việc sử dụng các lỗi 404 giả như một phương tiện để che giấu kiểm duyệt cũng đã được báo cáo ở Thái Lan và Tunisia. Ở Tunisia, nơi kiểm duyệt nghiêm trọng trước cuộc cách mạng năm 2011, mọi người đã nhận thức được bản chất của lỗi 404 giả và tạo ra một nhân vật tưởng tượng có tên "Ammar 404" đại diện cho "người kiểm duyệt vô hình".

Tại sao không chỉ đơn giản là trả lời với một cái gì đó như thế này?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google luôn trả lại 200 dưới dạng mã trạng thái trong API mã hóa địa lý của họ, ngay cả khi yêu cầu không thành công về mặt logic: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook luôn trả lại 200 cho các yêu cầu HTTP thành công, ngay cả khi yêu cầu REST không thành công: https://developers.facebook.com/docs/graph-api/USE-graph-api/error-handling

Thật đơn giản, mã trạng thái HTTP dành cho các yêu cầu HTTP. API REST là của bạn, xác định mã trạng thái của bạn.

Một bản sao trong cơ sở dữ liệu phải là một 409 CONFLICT .

Tôi khuyên bạn nên sử dụng 422 UNPROCESSABLE ENTITY cho các lỗi xác nhận.

Tôi giải thích dài hơn về mã 4xx ở đây .

Mã trạng thái 304 Không được sửa đổi cũng sẽ tạo ra phản hồi chấp nhận được đối với yêu cầu trùng lặp. Điều này tương tự như xử lý một tiêu đề If-None-Matchsử dụng thẻ thực thể.

Theo tôi, câu trả lời của @ Piskvor là sự lựa chọn rõ ràng hơn cho những gì tôi nhận thấy là mục đích của câu hỏi ban đầu, nhưng tôi có một cách thay thế cũng phù hợp.

Nếu bạn muốn coi một yêu cầu trùng lặp là một cảnh báo hoặc thông báo chứ không phải là một lỗi, mã trạng thái phản hồi của 304Không được sửa đổi vàContent-Location tiêu đề xác định tài nguyên hiện có sẽ có giá trị. Khi mục đích chỉ đơn thuần là để đảm bảo rằng tài nguyên tồn tại, một yêu cầu trùng lặp sẽ không phải là lỗi mà là xác nhận. Yêu cầu không sai, nhưng đơn giản là dư thừa và khách hàng có thể tham khảo tài nguyên hiện có.

Nói cách khác, yêu cầu là tốt, nhưng vì tài nguyên đã tồn tại, nên máy chủ không cần thực hiện bất kỳ xử lý nào nữa.

Bộ điều hợp ActiveRecord của Ember-Data dự kiến ​​sẽ 422 UNPROCESSABLE ENTITYđược trả về từ máy chủ. Vì vậy, nếu khách hàng của bạn được viết bằng Ember.js, bạn nên sử dụng 422. Chỉ sau đó DS.Errors sẽ được đưa ra với các lỗi được trả về. Tất nhiên bạn có thể thay đổi 422 thành bất kỳ mã nào khác trong bộ điều hợp của bạn.