Kiểu tương tác dựa trên sự kiện trong REST

Question

Tôi hiện đang vật lộn với một vấn đề thiết kế liên quan đến REST. Ứng dụng tôi đang thiết kế có một yêu cầu để gửi các sự kiện và cũng hỗ trợ phong cách pub/sub của sự tương tác. Tôi không thể đưa ra một thiết kế để cung cấp các kiểu tương tác này mà không vi phạm ràng buộc “Tương tác không quốc tịch” của REST. Tôi không chống lại bỏ phiếu như một số người dường như (bỏ phiếu hút), nhưng ứng dụng của tôi đòi hỏi một sự kiện dựa trên phong cách pub/sub của sự tương tác (bỏ phiếu không phải là một lựa chọn cho tôi). Vì vậy, câu hỏi của tôi là:

1. Tôi có thể thiết kế một ứng dụng RESTful hỗ trợ sự kiện dựa trên và tương tác pub/sub mà không vi phạm ràng buộc REST không?
2. Kiểu REST có phù hợp với kiểu tương tác này không?

Answer 1

Tôi khuyên bạn nên sử dụng Distributed Observer Pattern bởi Duncan Cragg để đọc tốt (hơi khó để bẻ khóa nhưng đáng để thử).

Vì những người khác đã cho biết khả năng bạn sẽ cần phải sử dụng bỏ phiếu nhưng khi bạn nói đúng người đăng ký có thể đăng ký sở thích của họ (POST để tạo đăng ký).Nếu bạn xem đăng ký làm tài nguyên của riêng mình, hợp đồng giữa nhà xuất bản và người đăng ký, thì tôi sẽ không xem đó là ràng buộc REST phá vỡ (xem Nhà nước và quốc tịch tại trang 217 của RESTful Web Services cho sự khác biệt giữa đơn đăng ký và trạng thái tài nguyên)

Answer 2

Tôi không thấy lý do khiến giao diện RESTful không hỗ trợ sự kiện.

Nó sẽ phải được thực hiện thông qua bỏ phiếu, nhớ bạn; và điều đó sẽ đúng ngay cả khi bạn sử dụng SOAP.

Mặc dù các máy chủ web của bạn chắc chắn vẫn không trạng thái, bạn có thể có một DB ở đâu đó ở mặt sau. Bạn có thể sử dụng DB này để xử lý các đăng ký cho các sự kiện bằng cách thêm một bảng đăng ký.

Answer 3

Tôi giả sử bạn có nghĩa là máy chủ phải thông báo cho khách hàng về các sự kiện. Tôi không thấy công nghệ cụ thể quan trọng như thế nào: bạn sẽ phải đối mặt với cùng một vấn đề, và phải chọn giải pháp từ cùng một nhóm, bất kể sử dụng các dịch vụ web dựa trên REST, SOAP hay bất kỳ phương án thay thế nào khác.

Câu hỏi cơ bản là, máy chủ của bạn có thể bắt đầu kết nối không? Bổ sung này, các khách hàng có thể nghe một cổng không? Nếu vậy, khách hàng đăng ký (phụ) và máy chủ thông báo về các sự kiện (pub). Cả hoạt động đăng ký và các sự kiện thông báo đều có thể là RESTful.

Bạn cần cả kết nối do máy chủ khởi tạo và ứng dụng khách nghe. Nếu một trong hai không phải là một tùy chọn (ví dụ, vì khách hàng là một trình duyệt web), bạn sẽ phải làm gì với việc bỏ phiếu (bạn cũng có thể xem xét một thứ gì đó như websockets, nếu bạn đang xử lý một trình duyệt). Thiết kế phiếu thăm dò ý kiến ​​của bạn một cách cẩn thận: phản hồi của máy chủ đối với sự kiện bỏ phiếu sẽ cho biết độ trễ tối thiểu trước khi khách hàng có thể thăm dò ý kiến ​​một lần nữa. Việc thực thi ban đầu của máy chủ có thể trả về một hằng số cho giá trị trễ này, nhưng sau này (giả sử các máy khách được xử lý tốt) điều này sẽ cho phép bạn kiểm soát tải trên máy chủ, phân biệt giữa các máy khách quan trọng và ít quan trọng, trên.

Và tất nhiên, việc bỏ phiếu có thể là RESTful.

Answer 4

Here là cuộc thảo luận về chủ đề của Roy.

Answer 5

Chỉ cần một tấm séc nhanh trên những ràng buộc REST:

• kiến ​​trúc client-server
• stateless
• bộ nhớ cache
• giao diện thống nhất
  • xác định các tài nguyên
  • thao tác của tài nguyên thông qua cơ quan đại diện
  • thông điệp tự desriptive
  • hypermedia của động cơ của trạng thái ứng dụng
• lớp hệ thống
• mã theo yêu cầu (tùy chọn)

Từ luận án Fielding:

Phong cách client-server là thường gặp nhất của phong cách kiến ​​trúc cho các ứng dụng dựa trên mạng. Máy chủ thành phần, cung cấp một bộ dịch vụ, lắng nghe các yêu cầu trên các dịch vụ đó. Một thành phần máy khách, mong muốn một dịch vụ được thực hiện, sẽ gửi một yêu cầu đến máy chủ thông qua một trình kết nối. Máy chủ hoặc từ chối hoặc thực hiện yêu cầu và gửi trả lời lại cho ứng dụng .

Btw. một hệ thống dựa trên sự kiện có lẽ sẽ vi phạm hầu hết các ràng buộc. Thật khó có thể xác định những thứ như hypermedia the engine of application state mà không cần khách hàng (kể từ khi tên khác của application state là client state) và siêu liên kết (vì chúng là vô nghĩa bởi pub/sub), và vân vân ...

Anyways nó là một câu hỏi thú vị như thế nào để thiết kế một hệ thống dựa trên sự kiện tương tự như REST. Tôi nghĩ bạn nên xuất bản các thông điệp tự mô tả có chứa RDF, nhưng đó chỉ là một mẹo. Việc bỏ phiếu có thể là viable solution, nhưng nếu tôi là bạn, tôi sẽ không cố gắng buộc REST trên hệ thống dựa trên sự kiện ...

cập nhật 2016.05.15.

Theo tôi hiểu kiến ​​trúc máy chủ - máy chủ - Fielding mô tả here và here trong luận án của mình - luôn sử dụng giao tiếp REQ/REP. Máy khách gửi yêu cầu và dịch vụ REST phản hồi. Nếu bạn muốn có một cái gì đó như PUB/SUB mà không vi phạm ràng buộc máy khách - máy chủ, cách duy nhất để làm điều đó là việc sử dụng bỏ phiếu. Nếu bạn không muốn sử dụng polling, thì ofc. bạn có thể sử dụng dịch vụ REST và dịch vụ websocket cùng nhau, nó không bị cấm ...

Answer 6

Câu hỏi trên web là câu trả lời cho vấn đề này. Chúng cho phép các sự kiện mà không vi phạm các nguyên tắc REST.