Ràng buộc duy nhất trong kiến ​​trúc RESTFul

Question

Với 15 năm kinh nghiệm phát triển phần mềm máy khách-nhà nước (và đó là vấn đề vốn có) Tôi vẫn đang cố gắng nắm bắt khái niệm về trạng thái không trạng thái trong kiến ​​trúc RestFul.

Giả sử tôi có giao diện chung để đăng đối tượng kinh doanh vào dịch vụ REST của mình. Ví dụ tài nguyên người dùng. Tài nguyên người dùng của tôi phải có ràng buộc về tính duy nhất của địa chỉ email của anh ấy. Phản ứng ban đầu của tôi là sử dụng các cơ sở dữ liệu cơ bản để "garantuee" này. Phản ứng thứ hai là giới thiệu một số cơ chế khóa hoặc giao dịch.

Nhưng đồng nghiệp của tôi ở Restafarian phản hồi: 'Không!' Khách hàng nên kiểm tra xem email cho người dùng mới có phải là duy nhất hay không và bạn chỉ nên chấp nhận thực tế rằng có một thời gian nhỏ trong đó có thể chèn địa chỉ email trùng lặp. Ứng dụng khách sẽ có thể xử lý xung đột này.

Điều này lại đi ngược lại mọi thứ tôi đã học và không cảm thấy tự nhiên chút nào. Vui lòng khai sáng cho tôi ...

Answer 1

Tôi không thấy lý do nào để không trả về HTTP code thích hợp: 409 Xung đột. Điều này có thể được trả lại khi nhận được lỗi từ cơ sở dữ liệu của bạn.

Rất tốt vì lý do khả năng sử dụng để kiểm tra xem địa chỉ e-mail là duy nhất trước khi gửi yêu cầu vì bạn có thể nhắc người dùng (và vô hiệu hóa gửi) để khắc phục sự cố. Trong mọi trường hợp xác minh phía máy chủ vẫn được khuyên.

Answer 2

Điều này không liên quan gì đến trạng thái phi trạng thái giao thức. Statelessness chỉ nói rằng máy chủ không nên là một trạng thái liên quan đến phiên lưu (http://en.wikipedia.org/wiki/Stateless_protocol).

Trong trường hợp của bạn, tài nguyên người dùng không phải là trạng thái phiên - chúng là tài nguyên liên tục được lưu trữ và được máy chủ tiếp xúc. Không có lý do gì để statinness buộc client phải thực hiện việc kiểm tra này (bằng cách tìm nạp lại và kiểm tra tất cả các tài nguyên User), và nó có ý nghĩa hơn khi có máy chủ làm điều đó. Việc kiểm tra này có được thực hiện bởi máy chủ như là một phần của POSTING tài nguyên Người dùng mới hay không tồn tại một tài nguyên riêng biệt cho phép kiểm tra này - về cơ bản không có sự khác biệt nào vì máy chủ đang thực hiện kiểm tra này theo cách khác. Nếu bạn sử dụng một tài nguyên riêng biệt để kiểm tra đầu tiên nếu nó là OK để POST một người dùng mới, và sau đó thực hiện một yêu cầu mới để thực sự làm POST - sau đó có khả năng địa chỉ e-mail trùng lặp. Trong trường hợp này, hành vi mong đợi là máy chủ thông báo cho máy khách rằng yêu cầu POST đã thất bại (sử dụng mã phản hồi HTTP thích hợp, giống như yêu cầu đầu tiên mà khách hàng đã kiểm tra xem e-mail có OK) không.

Tóm lại: máy chủ thực hiện "kiểm tra" và ứng dụng khách sẽ có thể xử lý các tình huống mà máy chủ thông báo rằng séc không thành công.