Có thể REST trong thực tế thực sự là phi trạng thái?

Question

Xem xét tình huống.

Tôi đang viết một ứng dụng phân tích thống kê. Ứng dụng có nhiều tầng.

1. Giao diện người dùng giao diện được viết cho nhiều loại thiết bị, máy tính để bàn, trình duyệt, thiết bị di động.
2. servlet hạng trung cung cấp dịch vụ REST được gọi là các giao diện người dùng này.
3. Phụ trợ thực hiện tính toán cực đoan của việc xử lý thống kê .
4. nào giao tiếp với một cơ sở dữ liệu phụ trợ thêm

Do lý do mà phân tích thống kê đòi hỏi số lượng lớn sức mạnh xử lý, bạn sẽ không bao giờ mơ về ủy thác chế biến đó cho front-end.

1. Phân tích thống kê bao gồm các quy trình hoặc chuỗi các bước luồng công việc.

2. Một số bước có thể yêu cầu quá nhiều sức mạnh xử lý, bạn sẽ không muốn lặp lại chúng.

3. Nếu bạn có quy trình 20 bước, bạn không thể thực hiện bước 20 mà không thực hiện bước 19 đầu tiên, không thể thực hiện được mà không cần bước thực hiện đầu tiên 18, v.v.

4. Có các điểm quan sát, ví dụ: thống kê phải kiểm tra kết quả của các bước 3, 7, 9, 14, 19 trước khi yêu cầu phía máy khách tiến hành bước tiếp theo.

5. Mỗi bước trong số này là một yêu cầu được gọi là dịch vụ REST, để thông báo cho siêu máy tính phụ trợ để thiết lập dần mô hình thống kê trong bộ nhớ.

6. Có nhiều quy trình công việc. Một số quy trình công việc có thể tình cờ chia sẻ các kết quả bước . ví dụ: Flow [dry]: Step [7] có thể chia sẻ Flow [wet]: Step [10]. Do với số lượng xử lý liên quan, chúng tôi hoàn toàn ngăn chặn lặp lại một bước có thể xảy ra một cách tình cờ đã là được thực hiện bởi một luồng khác.

Do đó, bạn có thể thấy rằng trong dịch vụ REST được thiết kế, không thể yêu cầu được độc lập với bất kỳ yêu cầu nào trước đó.

Do đó, câu lệnh sau có thể đúng như thế nào?

Tất cả tương tác REST là không trạng thái. Tức là, mỗi yêu cầu có chứa tất cả thông tin cần thiết cho trình kết nối để hiểu yêu cầu , không phụ thuộc vào bất kỳ yêu cầu nào có thể có trước đó.

Rõ ràng, ứng dụng tôi mô tả, yêu cầu yêu cầu đó phải phụ thuộc vào yêu cầu trước đó. Có ba khả năng mà tôi có thể thấy liên quan đến ứng dụng này.

• Ứng dụng của tôi không tuân thủ REST vì ứng dụng không tuân thủ yêu cầu không quốc tịch. Nó có thể sử dụng khung công tác JAX-RS, nhưng sử dụng JAX-RS và tất cả các bẫy của REST không làm cho nó trở thành REST, đơn giản chỉ vì nó không đạt được các tiêu chuẩn không trạng thái.
• Ứng dụng của tôi bị thiết kế tồi tệ - tôi nên bỏ qua cố gắng tránh chi phí tài chính và thời gian khôi phục mô hình thống kê ngay cả khi mất từ ​​5 - 15 phút cho luồng công việc. Chỉ cần đảm bảo không có sự phụ thuộc vào các yêu cầu trước đó. Lặp lại các bước tốn kém khi cần thiết.
• Tiêu chí không trạng thái là lỗi thời. Sự hiểu biết của tôi về REST là lỗi thời/lỗi trong cộng đồng REST đã liên tục bỏ qua tiêu chí này.

Ứng dụng của tôi có được coi là RESTful không?

Câu hỏi mới: ISO 9000

Cuối cùng, trong trường hợp ứng dụng của tôi không hoàn toàn coi RESTful, sẽ tất cả các tài liệu tham khảo để "nghỉ ngơi" cần phải được bỏ qua để vượt qua chứng chỉ ISO 9000?

chỉnh sửa mới:

REST trong mảnh

OK, đồng nghiệp của tôi và tôi đã thảo luận này và quyết định gọi như một kiến ​​trúc/mẫu REST trong mảnh = REST trong giai đoạn từng phần .

Answer 1

ISTM, bạn đang đọc quá nhiều vào trạng thái phi trạng thái. REST API hỗ trợ truyền thống CRUD operations. API cho CouchDB là ví dụ tốt về cách trạng thái DB được cập nhật bởi một loạt các giao dịch không quốc tịch.

Nhiệm vụ của bạn là xác định tài nguyên là gì và "chuyển trạng thái" giữa chúng. Mỗi bước trong luồng công việc của bạn là một chuyển trạng thái khác nhau, được đánh dấu bằng một URI khác. Mỗi cập nhật/thay đổi đối với tài nguyên có POST/PATCH kèm theo hoặc hoạt động PUT hoặc DELETE không có giá trị.

Nếu bạn muốn hiểu rõ hơn về ý nghĩa của việc RESTful và lý do đằng sau mỗi lựa chọn thiết kế, tôi khuyên bạn nên dành một giờ để đọc Chapter 5 of Roy Fielding's Dissertation.

Khi thực hiện các lựa chọn thiết kế, chỉ cần suy nghĩ về những nguyên tắc của thiết kế RESTful đang cố gắng thực hiện. Thiết lập thiết kế của bạn để các truy vấn được an toàn (không thay đổi trạng thái) và chúng được thực hiện theo cách có thể đánh dấu, có thể lưu trữ, phân phối, v.v. Hãy để từng bước trong luồng công việc chuyển sang trạng thái mới với URI riêng biệt rằng người dùng có thể sao lưu, phân nhánh theo các cách khác nhau, v.v. Toàn bộ ý tưởng là tạo ra thiết kế linh hoạt, có thể mở rộng.

Answer 2

Bạn đang cập nhật mô hình bộ nhớ thông qua REST api. Điều này có nghĩa là bạn đang duy trì trạng thái trên máy chủ giữa các yêu cầu.

Cách REST-ful để giải quyết điều này sẽ làm cho khách hàng duy trì trạng thái bằng cách đơn giản xử lý yêu cầu và trả lại tất cả thông tin để xây dựng yêu cầu tiếp theo trong phản hồi. Máy chủ sau đó xây dựng lại mô hình bộ nhớ từ thông tin trong yêu cầu và sau đó thực hiện điều đó. Bằng cách đó, nếu bạn hoạt động trong một ví dụmột môi trường nhóm, bất kỳ máy chủ nào có sẵn sẽ có thể xử lý yêu cầu.

Có hay không đây là cách hiệu quả nhất để thực hiện mọi thứ tùy thuộc vào đơn đăng ký của bạn. Có rất nhiều ứng dụng doanh nghiệp sử dụng phiên phía máy chủ và cân bằng tải phức tạp để đảm bảo rằng khách hàng luôn sử dụng cùng một nút trong một cụm. Vì vậy, có trạng thái phía máy chủ là một lựa chọn thiết kế hoàn toàn hợp lệ và có rất nhiều cách để thực hiện điều này một cách mạnh mẽ. Tuy nhiên, trạng thái phía máy chủ thường làm phức tạp việc mở rộng quy mô và REST theo nghĩa thuần túy nhất là tránh tình trạng phía máy chủ và tránh sự phức tạp.

Cách giải quyết/thỏa hiệp là duy trì trạng thái trong một số loại cơ sở dữ liệu hoặc cửa hàng. Bằng cách đó, các nút của bạn có thể tìm nạp trạng thái từ đĩa trước khi xử lý yêu cầu.

Tất cả phụ thuộc vào những gì bạn cần và những gì có thể chấp nhận được cho bạn. Như người bình luận trước đây đã đề cập, đừng quá hung hăng về toàn bộ điều này. Rõ ràng ai đó sẽ phải duy trì trạng thái và câu hỏi chỉ là điều tốt nhất là đặt trạng thái đó cho bạn và cách bạn truy cập nó. Về cơ bản có một vài sự cân bằng về cơ bản phải làm với các kịch bản kiểu if-if khác nhau. Ví dụ: nếu máy chủ gặp sự cố, bạn có muốn khách hàng của mình chạy lại toàn bộ các yêu cầu để tạo lại phép tính hay bạn chỉ muốn gửi lại yêu cầu cuối cùng? Tôi có thể tưởng tượng rằng bạn không thực sự cần tính sẵn sàng cao ở đây và không ngại rủi ro thấp mà đôi khi điều gì đó sai cho khách hàng của bạn. Trong trường hợp đó, có trạng thái ở phía máy chủ trong bộ nhớ là một giải pháp có thể chấp nhận được.

Giả sử máy chủ của bạn giữ trạng thái tính toán trong một số bản đồ băm, cách REST-ful để chuyển trạng thái xung quanh có thể đơn giản là gửi lại khóa cho mô hình trong phản hồi. Đó là một API REST-ful hoàn hảo và bạn có thể thay đổi việc triển khai để duy trì trạng thái hoặc thực hiện một việc khác mà không cần thay đổi API khi cần. Và đây là điểm chính của REST-ful: tách các chi tiết triển khai khỏi API. Khách hàng của bạn không cần biết nơi bạn đặt tiểu bang hoặc cách bạn lưu trữ trạng thái đó. Tất cả những gì nó cần là một biểu diễn tài nguyên của trạng thái đó có thể được điều khiển.

Tất nhiên, khóa phải được biểu diễn dưới dạng URI. Tôi khuyên bạn nên đọc "REST trong thực tế" của Jim Webber. Đó là một giới thiệu tuyệt vời để thiết kế các API REST-ful.