Cách thiết kế cổng HTTP RESTful cho giao thức yêu cầu kết nối liên tục?

Question

Tôi đang làm việc với giao thức máy chủ/máy khách liên tục và tôi cần thiết kế một cổng RESTful. Tôi không có nhiều kinh nghiệm trong việc thiết kế các giao diện REST và tôi không hiểu cách xử lý (theo cách RESTful) các ID phiên cần thiết để duy trì các kết nối liên tục trên máy chủ và cách tôi thể hiện trạng thái máy chủ là tài nguyên.

Tôi hỏi điều này vì tôi không muốn kết thúc với kết quả RPC-ish có vẻ "RESTful".

Ngữ cảnh cụ thể của vấn đề: Tôi muốn cải thiện cổng REST ZooKeeper hiện có để hỗ trợ các nút và đồng hồ tạm thời. Một nút tạm thời tồn tại trong khi máy khách được kết nối với máy chủ.

Cảm ơn.

Answer 1

Cách thức mà tôi đã thực hiện việc này trong quá khứ tuân theo mẫu "vé" hoặc "biên nhận". Dịch vụ REST chấp nhận các yêu cầu cho một tài nguyên (một tên báo cáo, một znode, vv) và trả về một vé. Vé này (thường là một UUID hoặc một cái gì đó tương tự) có thể được sử dụng để đại diện cho một phiên. Các yêu cầu tiếp theo sử dụng vé này để kiểm tra trạng thái yêu cầu của họ. Để đảm bảo vé hết hạn, một trong hai trường hợp xảy ra; bạn có thể hết thời gian chờ vé, hoặc khi nhận được kết quả, khách hàng phải cung cấp một ACK (xác nhận) trở lại dịch vụ.

ví dụ:

Yêu cầu: GET/Zookeeper/znode/phù du/foo đáp ứng: 1234-1234-1234-1234

Yêu cầu: GET/Zookeeper/status/1234-1234-1234-1234 đáp ứng: LÀM VIỆC (hoặc KHÔNG CÓ L orI hoặc CHẶN HOẶC KHÔNG ĐƯỢC CHẤP NHẬN hoặc KHÔNG L FAI ...)

Yêu cầu: GET/zookeeper/status/1234-1234-1234-1234 Trả lời: ACQUIRED (hoặc CÓ S orN hoặc OK hoặc THÀNH CÔNG) hoặc một số giá trị ...)

Yêu cầu: GET/zookeeper/acknowledledge/1234-1234-1234-1234 Phản hồi: OK (hoặc VÉ UNKNOWN, vv)

Thú vị thông điệp quản lý:

Yêu cầu: GET/Zookeeper/phiên (hoặc/vé) đáp ứng: [1234, 5668, ...]

Yêu cầu : GET/zookeeper/kill/ Trả lời: OK (hoặc KHÔNG ĐƯỢC NỔI BẬT hoặc FAILED ...)

Điều này đã làm việc rất, rất tốt. Điều này có nghĩa là, tuy nhiên các dịch vụ REST là nhà nước mà làm cho những thứ như cân bằng tải phức tạp hơn. Tôi đã sử dụng một giao thức đảm bảo một ID máy chủ được trả về với mỗi phản hồi và nếu khách hàng nhận được một ID máy chủ khác và một vé UNKNOWN, bạn cho rằng dịch vụ mà bạn đang nói đến đã chết và bắt đầu lại. Điều này ngụ ý cân bằng tải dính (tức là round-robin sẽ không hoạt động ở đây). Dịch vụ REST cần phải được đa luồng để hỗ trợ thực hiện các yêu cầu này song song và cung cấp quyền truy cập vào cơ sở dữ liệu vé (thường là trong bộ nhớ, cấu trúc dữ liệu có thể đồng bộ hóa) cũng như chuỗi thời gian chờ của phiên/vé.

Hy vọng điều này sẽ hữu ích.