API Websocket замінити API REST?

У мене є програма, основна функція якої працює в режимі реального часу, через веб-розетки або тривале опитування.

Однак більша частина сайту написана RESTful способом, що приємно для додатків та інших клієнтів у майбутньому. Однак я думаю про перехід на API вебсокета для всіх функцій сайту, подалі від REST. Це полегшило б мені інтегрувати функції реального часу у всі частини сайту. Чи ускладнить це створення програм або мобільних клієнтів?

Я виявив, що деякі люди вже роблять такі речі: SocketStream

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

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

Мій план - використовувати DNode , SocketIO та Backbone . За допомогою цих інструментів мої моделі Backbone та колекції можна передавати від / до клієнта та сервера, просто викликавши функції RPC-стилю. Більше не керувати кінцевими точками REST, серіалізувати / дезаріалізувати об'єкти тощо. Я ще не працював з socketstream, але, схоже, варто перевірити.

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

Мені буде цікаво слідкувати за вашими успіхами в дослідженні такого типу рішення. Якщо у вас є експерименти з github, будь ласка, вкажіть мене на них. У мене ще немає, але сподіваюся, що скоро.

Нижче наведено список посилань для читання, які я збирав пізніше. Я не можу сказати, що вони всі варті, тому що я лише скупив багато з них. Але, сподіваємось, деякі допоможуть.

Чудовий підручник з використання Socket.IO з Express. Він виставляє експрес-сеанси на socket.io та обговорює, як мати різні кімнати для кожного аутентифікованого користувача.

• http://www.danielbaulig.de/socket-ioexpress/

Підручник по node.js / socket.io / backbone.js / express / connect / jade / redis з аутентифікацією, хостинг Joyent тощо.

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Підручник з використання Pusher з Backbone.js (з використанням Rails):

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

Створіть додаток з backbone.js на клієнті та node.js з express, socket.io, dnode на сервері.

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Використання хребта з DNode:

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

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

Зв'язок із запитом-відповіддю проти Push

Використовуйте WebSockets лише в разі потреби PUSH даних від сервера до клієнта, що шаблон зв'язку не входить в HTTP (тільки обхідні шляхи). PUSH корисний, якщо події, створені іншими клієнтами, повинні бути доступними для інших підключених клієнтів, наприклад, в іграх, де користувачі повинні діяти на поведінку інших клієнтів. Або якщо ваш веб-сайт щось відстежує, коли сервер постійно надсилає дані клієнту, наприклад, фондові ринки (наживо).

Якщо вам не потрібно PUSH даних з сервера, зазвичай простіше використовувати сервер HTTP REST без стану. HTTP використовує просту схему зв'язку " Запит-відповідь" .

Я думаю про перехід на api WebSocket для всіх функцій сайту

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

WebSocket - це більш ефективний протокол, ніж RESTful HTTP, але все-таки RESTful HTTP забиває більше WebSocket у нижчих областях.

1. Ресурси створення / оновлення / видалення добре визначені для HTTP. Ви повинні реалізувати ці операції на низькому рівні для WebSockets.

2. З'єднання WebSocket масштабуються вертикально на одному сервері, де HTTP-з'єднання масштабуються горизонтально. Існує кілька фірмових нестандартних рішень для горизонтального масштабування WebSocket.

3. HTTP поставляється з великою кількістю хороших функцій, таких як кешування, маршрутизація, мультиплексування, gzipping тощо. Вони повинні будуватися поверх Websocket, якщо ви вибрали Websocket.

4. Оптимізація пошукової системи добре працює для HTTP-URL-адрес.

5. Усі проксі, DNS, брандмауэры ще не повністю усвідомлюють трафік WebSocket. Вони дозволяють порт 80, але можуть обмежити трафік, перенісши його спочатку.

6. Безпека за допомогою WebSocket - це підхід «майже або нічого».

Погляньте на цю статтю для більш детальної інформації.

Єдина проблема, яку я можу використовувати TCP (WebSockets) в якості основної стратегії доставки веб-контенту, - це те, що там дуже мало читає матеріалів про те, як створити архітектуру та інфраструктуру веб-сайту за допомогою TCP.

Таким чином, ви не можете вчитися на чужих помилках, і розвиток буде повільнішим. Це також не "перевірена" стратегія.

Звичайно, ви також втратите всі переваги HTTP (більші переваги мають стан без громадянства та кешування).

Пам'ятайте, що HTTP - це абстракція для TCP, призначена для розміщення веб-контенту.

І не будемо забувати, що SEO та пошукові системи не роблять веб-розетки. Тож ви можете забути про SEO.

Особисто я б рекомендував проти цього, оскільки існує занадто великий ризик.

Не використовуйте WS для розміщення веб-сайтів, використовуйте його для розміщення веб-додатків

Однак якщо у вас є іграшка чи особисті веб-сайти, будь-ласка, займіться нею. Спробуйте, будьте передовим. Для бізнесу чи компанії ви не можете виправдати ризик цього зробити.

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

Це почалося з доказу концепції, і працювало чудово. Але тоді, коли ми хотіли зробити це доступним для публіки, нам довелося додати сеанс користувача, тому нам були потрібні функції входу. І як би ви не дивилися на це, вебсокет повинен знати, з яким користувачем він має справу, так ми взяли ярлик використання веб-сокетів для аутентифікації користувачів . Це здавалося очевидним, і це було зручно.

Нам фактично довелося провести тишу деякий час, щоб зробити зв’язки надійними. Ми розпочали з деяких дешевих навчальних посібників для веб-сокетів, але виявили, що наша реалізація не змогла автоматично підключитися під час розриву зв’язку. Це все покращилося, коли ми перейшли на socket-io. Socket-io - це обов’язково!

Сказавши все це, чесно кажучи, я думаю, що ми пропустили деякі чудові функції socket-io.Socket-io може запропонувати ще багато, і я впевнений, якщо ви врахуєте це у своєму первісному дизайні, ви можете отримати більше від нього. На відміну від цього, ми просто замінили старі веб-розетки функціями websocket socket-io, і це було все. (немає кімнат, немає каналів, ...) Перероблення могло б зробити все більш потужним. Але ми на це не встигли. Це щось запам'ятати для нашого наступного проекту.

Далі ми почали зберігати все більше даних (історія користувача, рахунки-фактури, транзакції, ...). Ми зберігали все це в базі даних AWS dynamodb, і ПРОТИ, ми використовували socket-io для передачі операцій CRUD від переднього кінця до бекенда. Я думаю, що ми помилилися там. Це була помилка.

• Тому що незабаром ми з'ясували, що хмарні сервіси Amazon (AWS) пропонують чудові інструменти для балансування / масштабування навантаження для RESTful додатків .
• Зараз у нас складається враження, що нам потрібно написати багато коду для виконання рукостискань операцій CRUD.
• Нещодавно ми реалізували інтеграцію Paypal. Нам вдалося змусити його працювати. Але знову ж таки, всі підручники роблять це за допомогою RESTful API . Нам довелося переписувати / переосмислювати їх приклади, щоб реалізувати їх за допомогою веб-розетки. Ми дістали це працювати досить швидко, хоча. Але відчувається, що ми йдемо проти течії.

Сказавши все це, ми будемо жити наступного тижня. Ми потрапили вчасно, все працює. І це швидко, але чи буде масштабуватися?

Я б розглядав можливість використання обох . Кожна технологія має свої достоїнства, і не існує однорозмірного рішення, яке підходить для кожного рішення

Розмежування роботи йде таким чином:

1. WebSockets був би основним методом програми для спілкування з сервером, де потрібен сеанс. Це усуває багато хак, які потрібні для старих браузерів (проблема полягає в підтримці старих браузерів, що усуне це)

2. API RESTful використовується для GET-дзвінків, не орієнтованих на сеанс (тобто не потрібна автентифікація), які отримують користь від кешування браузера. Хорошим прикладом цього можуть слугувати довідкові дані для спадів, що використовуються веб-додатком. Однак. може змінитися трохи частіше, ніж ...

3. HTML та Javascript. Вони містять інтерфейс користувача webapp. Це, як правило, вигідно розмістити на CDN.

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

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

Для мобільного додатку веб-розетки не можуть знову підключитися до відключеного сеансу ( Як підключитися до веб-сокета після тісного з'єднання ) і керувати цим не тривіально. Так і для мобільних додатків я все-таки рекомендую API REST та опитування.

Ще одна річ, на яку слід звернути увагу при використанні WebSockets vs REST - це масштабованість . Сеансами WebSocket все ще керує сервер. API RESTful при правильному виконанні без стану (а це означає, що немає стану сервера, яким потрібно керувати), тому масштабованість може зростати горизонтально (що дешевше), ніж вертикально .

Чи хочу оновлення з сервера?

• Так: Socket.io
• Ні: REST

Недоліками Socket.io є:

• Масштабованість: WebSockets вимагають відкритих підключень та значно іншого налаштування Ops для веб-масштабу.
• Learnin: У мене немає необмеженого часу на навчання. Треба робити справи!

Я все одно буду використовувати Socket.io у своєму проекті, але не для основних веб-форм, які REST чудово зробить.

Транспорт на основі WebSockets (або тривалий опитування) в основному служить для (найближчого) спілкування в режимі реального часу між сервером і клієнтом. Хоча існують численні сценарії, коли потрібні такі види транспорту, як чат або якісь канали в режимі реального часу або інші речі, не всі частини певної веб-програми повинні бути обов'язково з'єднані двосторонньо із сервером.

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

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

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

Словом, ТАК

У публікації містяться всі найкращі практики для такого типу API.

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