REST hoặc một hàng đợi tin nhắn trong một hệ thống không đồng nhất nhiều tầng?

Tôi đang thiết kế API REST cho hệ thống ba lớp như: Client application-> Front-end API cloud server-> user's home API server (Home).

Homelà một thiết bị gia đình và được cho là duy trì kết nối Front-endthông qua Websocket hoặc một cuộc thăm dò dài (đây là nơi đầu tiên chúng tôi vi phạm REST. Nó thậm chí còn tồi tệ hơn về sau) . Front-endchủ yếu là các đường hầm Clientyêu cầu Homekết nối và xử lý một số cuộc gọi. Đôi khi Homegửi thông báo đến Client.

Front-endvà Homevề cơ bản có cùng API; Clientcó thể được kết nối Hometrực tiếp, qua mạng LAN. Trong trường hợp này, Homecần phải đăng ký một số Clienthành động trên Front-endchính nó.

Ưu điểm cho REST trong hệ thống này là:

• REST là con người có thể đọc được;
• REST có một ánh xạ được xác định rõ các động từ (như CRUD), danh từ và mã phản hồi cho các đối tượng giao thức;
• Nó hoạt động trên HTTP và vượt qua tất cả các proxy có thể;

Các phương thức REST là:

• Chúng tôi không chỉ cần một phong cách giao tiếp đáp ứng yêu cầu, mà còn cần một đăng ký xuất bản;
• Mã lỗi HTTP có thể không đủ để xử lý lỗi giao tiếp ba lớp; Front-endcó thể quay lại 202 Acceptedmột số cuộc gọi không đồng bộ chỉ để biết rằng Homekết nối cần thiết đã bị hỏng và đáng lẽ phải có 503;
• Homecần gửi tin nhắn đến Client. Clientsẽ phải bỏ phiếu Front-endhoặc để duy trì kết nối.

Chúng tôi đang xem xét WAMP / Autobahn qua Websocket để có được chức năng xuất bản / đăng ký, khi tôi nhận ra rằng nó trông giống như một hàng đợi tin nhắn.

Có đáng để đánh giá một loại hàng đợi nhắn tin như một phương tiện giao thông không?

Có vẻ như các hàng đợi tin nhắn là:

• Tôi sẽ cần tự xác định động từ CRUD và mã lỗi ở cấp độ tin nhắn.
• Tôi đã đọc một cái gì đó về "chi phí bảo trì cao hơn", nhưng nó có nghĩa là gì?

Những cân nhắc này nghiêm trọng như thế nào?

Nếu bạn có kết nối, hãy đi với hàng đợi tin nhắn - mặc dù bạn phải xác định các giao thức của riêng mình (hầu như không phải là một nhiệm vụ khó khăn!) Để gửi tin nhắn có cấu trúc và định dạng cụ thể.

Vấn đề với bảo trì là thông thường máy khách và máy chủ được xây dựng riêng biệt, do đó bạn cần cẩn thận để giữ cả hai đầu sử dụng cùng một định nghĩa thông báo, nhưng nếu bạn không tổ chức đủ, chỉ cần sử dụng cùng một XML bạn sẽ sử dụng trong REST dịch vụ.

Nếu bạn gặp sự cố kết nối qua internet, chỉ với cổng 80 và http và 'không theo hướng' thì hệ thống kiểu REST có lẽ là tốt nhất. Gửi và thăm dò ý kiến, hoặc nhận một websocket cho dữ liệu gọi lại, nhưng nói chung kiến ​​trúc sư hệ thống của bạn là máy khách / máy chủ. Nếu bạn có khả năng để có được kết nối, thì hệ thống nhắn tin là tuyệt vời.

Tôi sẽ sử dụng ZeroMQ cho một hệ thống nhắn tin, nó có thể cấu hình đủ để xoay theo mọi tình huống, bao gồm cả các tình huống chịu lỗi. Tôi không chắc chắn rằng nó hoạt động trên http mặc dù.

Có vẻ như Autobahn rất phù hợp với những gì bạn đang cố gắng thực hiện. Có những công cụ khác có sẵn là tốt. Kiểm tra Windows Azure Service Bus (có khung máy khách cho Java, .NET, PHP, Python, NodeJS và Ruby).

Trong khi các tin nhắn được xây dựng trong phần còn lại là hữu ích. Bạn sẽ thấy rằng ứng dụng của bạn sẽ vượt xa các hoạt động CRUD cơ bản. Ví dụ, nếu ứng dụng của bạn là một hệ thống ngân hàng. Thay vì

Cập nhật số dư Acct 54321 = Số dư - 20,00 Cập nhật Số dư 98765 = Số dư + 20,00

Bạn có thể muốn một tin nhắn như

Chuyển 20.00 từ tài khoản 54321 sang tài khoản 98765

Tốt nhất là bạn phát hiện ra trở ngại này với REST bây giờ hơn là sau này. Hãy xem Trung tâm sự kiện của Greg Young thảo luận về cách tạo một mô hình phong phú hơn để nhắn tin trong ứng dụng của bạn.