Websocket API для замены REST API?

У меня есть приложение, основная функция которого работает в режиме реального времени, через веб-сокеты или длинный опрос.

Однако большая часть сайта написана в стиле RESTful, что будет удобно для приложений и других клиентов в будущем. Однако я подумываю о переходе на API-интерфейс websocket для всех функций сайта вдали от 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/

Использование Backbone с DNode:

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introduction-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 имеет множество хороших функций, таких как кеширование, маршрутизация, мультиплексирование, сжатие и т. Д. Они должны быть построены поверх Websocket, если вы выбрали Websocket.

4. Оптимизация поисковых систем хорошо работает для URL-адресов HTTP.

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 может предложить гораздо больше, и я уверен, что если вы учтете это в своем первоначальном дизайне, вы сможете получить от него больше. Напротив, мы просто заменили старые веб-сокеты на функциональность веб-сокетов socket-io, и на этом все. (без комнат, без каналов, ...) Редизайн мог бы сделать все более мощным. Но у нас не было на это времени. Об этом нужно помнить для нашего следующего проекта.

Затем мы начали хранить все больше и больше данных (история пользователей, счета, транзакции, ...). Мы сохранили все это в базе данных AWS Dynamodb и СНОВА использовали socket-io для передачи операций CRUD от внешнего интерфейса к серверному. Думаю, мы тут не туда свернули. Это была ошибка.

• Потому что вскоре после этого мы узнали, что облачные сервисы Amazon (AWS) предлагают отличные инструменты балансировки / масштабирования нагрузки для приложений RESTful .
• Теперь у нас сложилось впечатление, что нам нужно написать много кода для подтверждения операций CRUD.
• Недавно мы реализовали интеграцию с Paypal. Нам удалось заставить его работать. Но опять же, все руководства делают это с помощью RESTful API . Нам пришлось переписать / переосмыслить их примеры, чтобы реализовать их с помощью веб-сокетов. Однако мы заставили его работать довольно быстро. Но кажется, что мы идем против течения.

Сказав все это, мы выйдем в эфир на следующей неделе. Доехали вовремя, все работает. И это быстро, но будет ли масштабироваться?

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

Разделение работы происходит следующим образом:

1. WebSockets будет основным методом приложения для связи с сервером, на котором требуется сеанс. Это устраняет множество хаков, которые необходимы для старых браузеров (проблема заключается в поддержке старых браузеров, которые устранят это)

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

3. HTML и Javascript. Они составляют пользовательский интерфейс веб-приложения. Как правило, их было бы выгодно разместить на CDN.

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

Все это происходит по протоколу HTTP, который уже позволяет использовать безопасные сокеты через SSL.

Однако для мобильного приложения веб-сокеты не могут повторно подключиться к отключенному сеансу ( как повторно подключиться к веб-сокету после закрытия соединения ), и управление этим нетривиально. Поэтому для мобильных приложений я бы по-прежнему рекомендовал REST API и опрос.

Еще одна вещь, на которую следует обратить внимание при использовании WebSockets против REST, - это масштабируемость . Сеансы WebSocket по-прежнему управляются сервером. RESTful API, если все сделано правильно, не имеет состояния (что означает, что нет состояния сервера, которым нужно управлять), поэтому масштабируемость может расти по горизонтали (что дешевле), чем по вертикали .

Мне нужны обновления с сервера?

• Да: Socket.io
• Нет: ОТДЫХ

Недостатки Socket.io:

• Масштабируемость: для веб-сокетов требуются открытые соединения и очень разные настройки Ops для веб-масштабирования.
• Learnin: У меня нет неограниченного времени для обучения. Дело должно быть сделано!

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

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

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

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

Я хотел бы указать на это сообщение в блоге, которое является лучшим ответом на этот вопрос.

Короче ДА

В публикации собраны все лучшие практики для такого рода API.

Это плохая идея. Стандарт еще даже не доработан, поддержка различается в зависимости от браузера и т. Д. Если вы захотите сделать это сейчас, вам придется откатиться на флэш-память или провести длинный опрос и т. Д. В будущем, вероятно, все еще не будет много смысла, поскольку сервер должен поддерживать, оставляя соединения открытыми для каждого пользователя. Вместо этого большинство веб-серверов спроектированы так, чтобы быстро отвечать на запросы и как можно быстрее закрывать их. Черт возьми, даже ваша операционная система должна быть настроена для работы с большим количеством одновременных подключений (каждое подключение использует больше эфемерных портов и памяти). Придерживайтесь использования REST для большей части сайта.