REST або черга повідомлень у багаторівневій гетерогенній системі?

Я розробляю API REST для трирівневої системи на зразок: Client application-> Front-end API cloud server-> user's home API server (Home).

Homeце домашній пристрій, і він повинен підтримувати зв’язок Front-endчерез Websocket або тривалий опитування (це перше місце, де ми порушуємо REST. Згодом стає ще гірше) . Front-endв основному тунелі Clientзапитують на Homeз'єднання та обробляють деякі дзвінки самі. Іноді Homeнадсилає сповіщення на адресу Client.

Front-endі Homeмають в основному той же API; Clientможливо підключення Homeбезпосередньо до локальної мережі. У цьому випадку Homeпотрібно зареєструвати деякі Clientдії на Front-endсебе.

Плюси для REST в цій системі:

• REST читається людиною;
• REST має чітко визначене відображення дієслів (наприклад, CRUD), іменників та кодів відповідей до об'єктів протоколу;
• Він працює через HTTP і передає всі можливі проксі;

Протипоказаннями REST є:

• Нам потрібен не лише стиль спілкування на відповідь на запит, але й публікація-підписка;
• Коди помилок HTTP можуть бути недостатніми для обробки трирівневих помилок зв'язку; Front-endВи можете повернутися 202 Acceptedдо якогось виклику асинхронізації лише для того, щоб дізнатись, що необхідне Homeз'єднання розірвано і воно повинно було бути 503;
• Homeпотрібно надсилати повідомлення Client. Clientдоведеться опитувати Front-endабо підтримувати зв’язок.

Ми розглядаємо WAMP / Autobahn через Websocket, щоб отримати функцію публікації / підписки, коли мені здалося, що це вже схоже на чергу повідомлень.

Чи варто оцінювати якусь чергу повідомлень як транспорт?

Схоже, протилежні черги повідомлень:

• Мені потрібно визначити CRUD дієслова та коди помилок на рівні повідомлення.
• Я читав щось про "більш високу вартість обслуговування", але що це означає?

наскільки серйозні ці міркування?

Якщо у вас є зв'язок, перейдіть з чергою повідомлень - хоча вам потрібно визначити власні протоколи (навряд чи складне завдання!) Для надсилання повідомлень певної структури та формату.

Проблема з технічним обслуговуванням полягає в тому, що зазвичай клієнт і сервер будуються окремо, тому вам потрібно бути обережним, щоб обидва кінці не використовували однакові визначення повідомлень, але якщо ви недостатньо організовані, просто використовуйте той самий XML, який ви використовували б у своєму REST сервіс.

Якщо у вас є проблеми з підключенням через Інтернет, лише з портами 80 та http та "однонаправленими" повідомленнями, тоді система стилю REST, мабуть, найкраща. Відправляйте та опитуйте або отримуйте веб-розетку для даних зворотного дзвінка, але, як правило, архітектором вашої системи буде клієнт / сервер. Якщо у вас є можливість отримати зв’язок, то системи обміну повідомленнями чудові.

Я б з ZeroMQ працював над системою обміну повідомленнями, достатньо настроюваною, щоб перекручуватись у будь-яких сценаріях, у тому числі і у відмовах . Я не впевнений, що він працює над http .

Схоже, що Автобан добре поєднується з тим, що ви намагаєтеся зробити. Є й інші інструменти. Перевірте службову шину Windows Azure (у якої є клієнтські рамки для Java, .NET, PHP, Python, NodeJS та Ruby).

Хоча вбудовані повідомлення про відпочинок корисні. Ви дізнаєтесь, що ваша програма переросте основні операції зі зв'язком із кліматом. Наприклад, якщо ваша заява була банківською системою. Замість

Оновити Acct 54321 Balance = Баланс - 20.00 Оновити Acct 98765 Balance = Баланс + 20.00

Напевно, ви хочете отримати одне повідомлення типу

Перевести 20.00 з рахунку 54321 на рахунок 98765

Краще, щоб ви виявили цю перешкоду з REST зараз, а не пізніше. Ознайомтеся з подією Центру подій Грега Янга, де йдеться про те, як створити більш багату модель для обміну повідомленнями у вашій програмі.