Websocket API для замены REST API?
У меня есть приложение, основная функция которого работает в режиме реального времени, через websockets или длинный опрос.
тем не менее, большая часть сайта написана в спокойной манере, что хорошо для приложений s и других клиентов в будущем. Тем не менее, я думаю о переходе на API websocket для всех функций сайта, вдали от REST. Это облегчило бы мне интеграцию функций реального времени во все части сайта. Это сделало бы его более трудным, чтобы построить приложения или мобильные клиенты?
Я обнаружил, что некоторые люди уже делают такое: SocketStream
8 ответов:
Не сказать, что другие ответы здесь не имеют заслуг, они делают некоторые хорошие моменты. Но я собираюсь пойти против общего консенсуса и согласиться с вами, что переход на websockets для большего, чем просто функции реального времени, очень привлекателен.
Я серьезно рассматриваю возможность перемещения моего приложения из Спокойной архитектуры в более RPC-стиль через websockets. Это не "игрушечное приложение", и я не говорю только о функциях в реальном времени, поэтому у меня есть оговорки. Но я вижу много преимуществ в движении по этому маршруту и чувствую, что это может оказаться исключительным решением.
мой план заключается в использовании DNode,SocketIO и основой. С помощью этих инструментов мои базовые модели и коллекции могут передаваться от/к клиенту и серверу, просто вызывая функции RPC-стиля. Больше нет управления конечными точками REST, сериализации / десериализации объектов и т. д. Я еще не работал с socketstream, но, похоже, стоит проверить из.
Мне еще предстоит пройти долгий путь, прежде чем я смогу окончательно сказать, что это хорошее решение, и я уверен, что это не лучшее решение для каждого приложения, но я убежден, что эта комбинация будет исключительно мощной. Я признаю, что есть некоторые недостатки, такие как потеря возможности кэшировать ресурсы. Но я чувствую, что преимущества перевесят их.
Мне было бы интересно следить за вашим прогрессом в изучении этого типа решения. Если у вас есть какие-либо эксперименты github, пожалуйста, укажите мне на них. У меня их еще нет, но надеюсь скоро.
Ниже приведен список ссылок для чтения позже, которые я собирал. Я не могу поручиться, что они все стоят, так как я только снял многие из них. Но, надеюсь, некоторые из них помогут.
отличный учебник по использованию Socket.IO с Экспресс. Он предоставляет экспресс-сеансы для socket.io и обсуждает, как иметь разные комнаты для каждой аутентификации пользователь.
самоучитель по узлу.с JS/гнездо.Ио/позвоночник.с JS/экспресс/подключения/Джейд/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/
учебник по использованию толкателя с позвоночником.js (используя Рельсы):
построить приложение с позвоночником.js на клиенте и узле.js с курьерским, 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, ваш сервер становится stateful и вам нужно иметь соединение с клиентом на сервере.
запрос-ответ связи против Push
использовать WebSockets, только если вам нужно PUSH данные с сервера на клиент, что шаблон связи не включен в HTTP (только обходные пути). PUSH полезен, если события, созданные другими клиентами, должны быть доступны другим подключенным клиентам, например, в играх, где пользователи должны действовать на поведение других клиентов. Или если ваш сайт отслеживает что-то, где сервер постоянно передает данные клиенту, например, фондовые рынки (live).
Если вам не нужно передавать данные с сервера, обычно проще использовать HTTP REST без состояния сервер. HTTP использует простой Запрос-Ответ шаблон общения.
Я думаю о переходе на WebSocket api для всех функций сайта
нет. Вы не должны этого делать. Нет никакого вреда, если вы поддерживаете обе модели. Используйте остальное для односторонней связи / простых запросов & WebSocket для двусторонней связи, особенно когда сервер хочет послать уведомление в режиме реального времени.
WebSocket является более эффективным протоколом, чем RESTful HTTP но все равно RESTful HTTP баллы по WebSocket в нижних областях.
создать/обновить / удалить ресурсы были определены хорошо для HTTP. Вы должны осуществить эти операции на низком уровне для WebSockets.
соединения WebSocket масштабируются вертикально на одном сервере, где как HTTP-соединения масштабируются горизонтально. Существуют некоторые собственные нестандартные решения для горизонтального масштабирования WebSocket .
HTTP и поставляется с множеством хороших функций, таких как кэширование, маршрутизация, мультиплексирование, сжатие и т. д. Они должны быть построены поверх Websocket, если вы выбрали Websocket.
поисковая оптимизация хорошо работает для HTTP-адресов.
все прокси-сервера, DNS-сервера, межсетевые экраны еще не полностью осведомлены о проксировании трафика. Они разрешают порт 80, но могут ограничить трафик, отслеживая его первый.
безопасность с WebSocket-это подход "все или ничего".
взгляните на это статьи для более подробной информации.
единственная проблема, которую я могу использовать TCP (WebSockets) в качестве основной стратегии доставки веб-контента, заключается в том, что там очень мало материала для чтения о том, как проектировать архитектуру и инфраструктуру вашего сайта с использованием TCP.
поэтому вы не можете учиться на ошибках других людей и развитие будет медленнее. Это также не "проверенная" стратегия.
конечно, вы также потеряете все преимущества HTTP (без сохранения состояния и кэширования большой плюс.)
помните, что HTTP-это абстракция для TCP, предназначенная для обслуживания веб-контента.
и давайте не будем забывать, что SEO и поисковые системы не делают websockets. Так что вы можете забыть о SEO.
лично я бы рекомендовал против этого, так как есть слишком большой риск.
не используйте WS для обслуживания веб-сайтов, используйте его для обслуживания веб-приложений
однако, если у вас есть игрушка или личные веб-сайты всеми значит вперед. Попробуйте, будьте передовыми. для бизнеса или компании вы не можете оправдать риск делать это.
Я бы рассмотрел использование обоих. Каждая технология имеет свои достоинства, и нет одного размера Подходит для всех решений.
разделение работы происходит следующим образом:
1) WebSockets будет основным методом приложения для связи с сервером, где требуется сеанс. Это устраняет многие хаки, которые необходимы для старых браузеров (проблема заключается в поддержке старых браузеров, которые устранят это)
2) RESTful API используется для GET вызовы, которые не ориентированы на сеанс (т. е. не требуется аутентификация), которые извлекают выгоду из кэширования браузера. Хорошим примером этого могут быть справочные данные для выпадающих списков, используемых веб-приложением. Однако. может меняться немного чаще, чем...
3) HTML и Javascript. Они включают в себя пользовательский интерфейс веб-приложения. Они, как правило, выиграют от размещения на CDN.
4) веб-службы, использующие WSDL, по-прежнему являются лучшим способом коммуникации на уровне предприятия и между предприятиями он обеспечивает хорошо определенный стандарт для передачи сообщений и данных. В первую очередь вы бы выгрузили это на устройство Datapower для прокси-сервера обработчика веб-службы.
все это происходит на протоколе HTTP, который дает использование secure sockets через SSL уже.
однако для мобильного приложения websockets не может повторно подключиться к отключенному сеансу (как подключиться к websocket после тесного соединения) и управление этим не тривиально. Так что для мобильных приложений, Я бы все равно рекомендовал REST API и опрос.
еще одна вещь, на которую следует обратить внимание при использовании WebSockets vs REST, - это масштабируемость. Сеансы WebSocket по-прежнему управляются сервером. RESTful API при правильном выполнении являются безгосударственными (что означает, что нет состояния сервера, которым необходимо управлять), поэтому масштабируемость может расти по горизонтали (что дешевле), чем по вертикали.
Мне нужны обновления с сервера?
- Да: Socket.io
- нет: остальные
минусы к Socket.io являются:
- масштабируемость: веб-сокетов требуют открытых подключений и многое другое Программа установки ОПС в веб-масштабе.
- Learnin: у меня нет неограниченного времени для моего обучения. Все должно быть сделано!
Я все равно буду использовать Socket.io в моем проекте, но не для основных веб-форм, которые REST будет делать мило.
WebSockets (или длинный опрос) на основе транспортов в основном служат для (около) связи в реальном времени между сервером и клиентом. Хотя существует множество сценариев, где требуются такие виды транспорта, такие как чат или какие-то каналы в реальном времени или другие вещи, не все части некоторых веб-приложений должны быть обязательно подключены двунаправленно с сервером.
REST-это архитектура на основе ресурсов, которая хорошо понимается и предлагает свои преимущества другая архитектура. WebSockets больше склоняются к потокам / каналам данных в режиме реального времени, что потребует от вас создать какую-то логику на основе сервера, чтобы приоритизировать или различать ресурсы и каналы (в случае, если вы не хотите использовать REST).
Я предполагаю, что в конечном итоге будет больше WebSockets ориентированных рамок, таких как socketstream в будущем, когда этот транспорт будет более широко распространен и лучше понятен / документирован в виде данных тип / форма агностической доставки. Однако, я думаю, это не означает, что он будет/должен заменить остальные только потому, что он предлагает функциональность, которая не обязательно требуется во многих случаях использования и сценариях.
Это не очень хорошая идея. Стандарт еще не завершен, поддержка варьируется в разных браузерах и т. д. Если вы хотите сделать это сейчас, вам в конечном итоге нужно будет вернуться к flash или длинному опросу и т. д. В будущем это, вероятно, все еще не будет иметь большого смысла, так как сервер должен поддерживать открытые соединения для каждого отдельного пользователя. Большинство веб-серверов предназначены для быстрого реагирования на запросы и их закрытия как можно быстрее. Даже ваша операционная система необходимо будет настроить для работы с большим количеством одновременных соединений (каждое соединение использует более эфемерные порты и память). Придерживайтесь использования REST для как можно большей части сайта.
Comments