Чи є продуктивність єдиною причиною не використовувати SignalR (websockets) повністю замість традиційного API REST?

Я використовував SignalRдля досягнення функцій обміну повідомленнями в реальному часі у кількох своїх проектах. Здається, працює надійно і дуже легко навчитися користуватися.

Спокуса, принаймні для мене, - відмовитися від розробки сервісу Web API і використовувати його SignalRдля всього.

Я відчуваю, що цього можна досягти продуманим дизайном, і якби це було, це означало б набагато менше клієнтського коду. Що ще важливіше, це означало б, що існував би єдиний інтерфейс для служб, а не розділений інтерфейс, і в гіршому випадку, що можна було б це зробити, не замислюючись про те, коли все буде надано тощо.

Отже, я хотів би знати:

1. Чи є якісь інші причини не використовувати SignalR замість усіх веб-сервісів, окрім продуктивності?
2. Чи достатньою є ефективність SignalR, щоб цього не було сенсу?

Вже давно мріють мати можливість перекладати визначення об’єктів і службових визначень на стороні сервера до коду доступу на стороні клієнта без чогось нерозумного node.js. Наприклад, якщо я визначаю цікавий об'єкт InterestingObjectі послугу для CRUDоб'єкта InterestingObjectService, я можу визначити стандартний маршрут URL до служби - скажімо, "/ {serviceName} / {methodName}" - але мені все одно потрібно написати клієнтський код для доступу сервіс. Оскільки об'єкт буде передаватися від клієнта до сервера і назад, немає ніякого практичного підстави матичітко визначити об'єкт у коді на стороні клієнта, а також не потрібно чітко визначати маршрути для виконання операцій CRUD. Я відчуваю, що повинен бути спосіб стандартизувати все це, щоб можна було записати клієнта за умови, що сервіс доступ працює від клієнта до сервера і назад так само прозоро, як це було б, якби я писав WinForms або Java Applet або Native App чи що у вас є.

Якщо SignalR досить хороший для використання замість традиційного веб-сервісу, це може бути життєздатним способом досягти цього. SignalR вже включає функціональність, щоб змусити хаб працювати як службу, яку я описую, тому я міг би визначити загальну базу (CRUD) послугу, яка б запропонувала всю цю функціональність поза коробкою з деяким відображенням. Тоді я майже міг прийняти як належний доступ до послуги, врятувавши мене від роздратування переписування коду, щоб отримати доступ до чогось, до якого можна отримати доступ за умовами, і що ще важливіше, час, який мені доведеться витратити на написання коду, щоб визначити, як це оновлено в ДОМ.

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

Ці дві технології мають зовсім інше призначення.

• REST призначений для звичайних дзвінків в API, при цьому клієнт є активним учасником обміну. Коли клієнту потрібно знайти GPS координати адреси, клієнт ініціює виклик в API і чекає, поки він отримає координати, або станеться помилка або пройде тайм-аут.

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

Різниця очевидна: у першому випадку клієнт вирішує, коли йому потрібна конкретна інформація; у другому випадку клієнт просто чекає, коли з ним зв’яжуться, і може не знати, коли це буде.

Якимось чином обидва є взаємозамінними: ви можете реалізовувати веб-сокети, коли вони вам не потрібні (тобто клієнт зателефонує на сервер через веб-сокети замість REST-дзвінка), і ви можете використовувати опитування або тривале опитування як заміну веб-розетки (враховуючи, що це успішно використовувалося роками, поки веб-розетки не стали настільки популярними).

Але їх взаємозамінність коштує:

• Коли ви використовуєте опитування або тривале опитування замість веб-розеток, ви часто витрачаєте пропускну здатність.

• Коли ви використовуєте веб-розетки для того, щоб зробити те, що можна зробити через веб-api, ви залишаєте відкритими всі з'єднання від усіх активних клієнтів, що може бути не тим, що ви дійсно хочете. Для невеликого веб-сайту, на якому ви очікуєте мати не більше 5 клієнтів одночасно, це не проблема. Для такої послуги, як Amazon AWS, це технічно вирішити непросто.

Не використовуйте веб-розетки, коли вони вам не потрібні. Щоб отримати GPS координати адреси, я нічого не отримую, відкриваючи з'єднання веб-розеток, здійснюючи дзвінок, чекаючи відповіді та закриваючи з'єднання: REST відповідає моїм потребам у таких сценаріях.

• Якщо ви неодноразово опиняєтесь і часто перевіряєте інформацію через дзвінок REST до служби, це може бути хорошим знаком того, що вам слід перейти до веб-розеток. Аналогічно, Переповнення стека зменшує використання пропускної здатності за допомогою веб-розеток, оскільки допомагає людям не витрачати час на натискання клавіші F5 на домашній сторінці, щоб побачити, чи є у них нові повідомлення.

• Якщо ви виявите, що ви відкриваєте підключення до веб-розеток, використовуйте їх для здійснення одного дзвінка, а потім закрийте їх, або якщо ваші з'єднання залишаються відкритими, але сервер щось надсилає клієнту лише за бажанням клієнта, перейдіть на REST.

Крім того, веб-розетки мають обмежену підтримку і їх не завжди легко здійснити. Хоча SignalR робить його легким у виконанні, це не означає, що у вас не виникне труднощів з його реалізацією в інших мовах / контекстах / середовищах. З REST це легко: це може бути curlдзвінок або подібна функція, доступна для кожної основної мови. З веб-розетками ви не можете бути впевнені, скільки часу знадобиться клієнту, використовуючи [вставте тут назву мови, якої ви ще не знаєте].

Я використовував веб-розетки в кількох проектах у .NET, Python та node.js.

• У .NET це було не надто складно, але все-таки я ще кілька днів пробував з'ясувати деякі криптовалютні проблеми, такі як зв’язок перервався, як тільки він відкрився. (Це було до SignalR; я ніколи не пробував SignalR). Я також використовував WCF в режимі веб-розеток, що теж не було проблем (але я вважаю, що у WCF завжди виникають проблеми).

• У node.js це було можливо, але мені довелося двічі перемикати бібліотеки, поки я не знайшов тієї, яка працює. Я вважаю, що я провів щонайменше тиждень, намагаючись зробити веб-розетки Hello World.

• У Python я спробував один раз, провів два-три дні і відмовився. Це ніколи не спрацювало.

Порівняйте це з REST: єдині проблеми, з якими можна зіткнутися з новою мовою / рамкою, - це знати, як розміщувати файли POST або отримувати дуже великий двійковий відповідь. Я пам’ятаю, що витратив кілька годин на пошук рішень для деяких мов. І все-таки кілька годин для особливого випадку - це ніщо в порівнянні з днями або тижнями для простого Hello World.

Тільки мої 2 копійки ...

Я думаю, що справа не в дійсності чи в чому б то не було. Йдеться про стандарти. REST - це стандарт, і IMHO має такі переваги:

• HTTP запити просто використовувати. Кожен може швидко використовувати API REST. Чорт, ви навіть можете відкрити веб-переглядач і ввести URL-адресу, щоб побачити дані, наскільки інтерактивнішими ви можете бути?
• (Майже) будь-яка мова програмування може ним користуватися. Це свого роду універсальний інтерфейс. Взаємодія з SignalR з екзотичної мови видається менш очевидною.
• Він має приємну підтримку інструментів, як http://petstore.swagger.wordnik.com/
• Це приємний "інтерфейс" для налагодження. Ви можете легко відстежувати вхідні та вихідні повідомлення безпосередньо в браузері, бачити дані і т. Д. З веб-розетками та користувацькими бібліотеками це не так очевидно, що вам потрібно чітко ввійти в журнал.