Mã phản hồi REST cho dữ liệu không hợp lệ

Mã phản hồi nào sẽ được chuyển cho khách hàng trong trường hợp sau đây?

1. Dữ liệu không hợp lệ được chuyển trong khi người dùng đăng ký như định dạng email sai
2. Tên người dùng / Email đã tồn tại

Tôi đã chọn 403. Tôi cũng thấy rằng tôi cảm thấy có thể sử dụng được.

Wikipedia:

412 Điều kiện tiên quyết không thành công: Máy chủ không đáp ứng một trong những điều kiện tiên quyết mà người yêu cầu đưa ra theo yêu cầu

Mã đề xuất nếu tôi nên sử dụng khác 403.

400 là sự lựa chọn tốt nhất trong cả hai trường hợp. Nếu bạn muốn làm rõ thêm lỗi, bạn có thể thay đổi Cụm từ Lý do hoặc bao gồm phần thân để giải thích lỗi.

412 - Điều kiện tiên quyết không thành công được sử dụng cho các yêu cầu có điều kiện khi sử dụng ngày và ETags được sửa đổi lần cuối.

403 - Cấm được sử dụng khi máy chủ muốn ngăn truy cập vào tài nguyên.

Sự lựa chọn duy nhất khác có thể là 422 - Thực thể không thể xử lý.

Tôi muốn giới thiệu 422. Nó không phải là một phần của thông số HTTP chính, nhưng nó được xác định bởi một tiêu chuẩn chung (WebDAV) và nó phải được các trình duyệt xử lý giống như bất kỳ mã trạng thái 4xx nào khác.

Từ RFC 4918 :

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.

Nếu yêu cầu không thể được phân tích cú pháp chính xác (bao gồm cả thực thể / cơ thể yêu cầu), phản hồi thích hợp là 400 Yêu cầu xấu [ 1 ].

RFC 4918 tuyên bố rằng 422 Thực thể không thể xử lý được áp dụng khi thực thể yêu cầu được hình thành tốt về mặt cú pháp, nhưng sai về mặt ngữ nghĩa. Vì vậy, nếu thực thể yêu cầu bị cắt xén (như định dạng email xấu), hãy sử dụng 400; nhưng nếu nó không có ý nghĩa (như @example.com) sử dụng 422.

Nếu vấn đề là, như đã nêu trong câu hỏi, tên người dùng / email đã tồn tại, bạn có thể sử dụng 409 Xung đột [ 2 ] với mô tả về xung đột và gợi ý về cách khắc phục (trong trường hợp này là "chọn một tên người dùng / email khác nhau "). Tuy nhiên, trong thông số kỹ thuật như đã viết, 403 Forbidden [ 3 ] cũng có thể được sử dụng trong trường hợp này, các đối số về ủy quyền HTTP mặc dù.

412 Điều kiện tiên quyết Không thành công [ 4 ] được sử dụng khi tiêu đề yêu cầu điều kiện tiên quyết (ví dụ If-Match) được cung cấp bởi khách hàng đánh giá là sai. Đó là, khách hàng yêu cầu một cái gì đó và cung cấp các điều kiện tiên quyết, biết rõ rằng những điều kiện tiên quyết đó có thể thất bại. 412 không bao giờ nên xuất hiện trên máy khách ngoài màu xanh và không nên liên quan đến thực thể yêu cầu mỗi se .

Thật thú vị khi quay lại 418 I'm a teapotcác yêu cầu rõ ràng là thủ công hoặc độc hại và "không thể xảy ra", chẳng hạn như không kiểm tra CSRF hoặc thiếu các thuộc tính yêu cầu.

2.3.2 418 Tôi là một ấm trà

Bất kỳ nỗ lực nào để pha cà phê bằng ấm trà sẽ dẫn đến mã lỗi "418 Tôi là một ấm trà". Cơ thể thực thể kết quả có thể ngắn và mập mạp.

Để giữ cho nó nghiêm túc một cách hợp lý, tôi hạn chế sử dụng các mã lỗi hài hước ở các điểm cuối RESTful không được tiếp xúc trực tiếp với người dùng.