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

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

однако большая часть сайта написана в спокойной манере, что приятно для приложений и других клиентов в будущем. Тем не менее, я думаю о переходе на API websocket для всех функций сайта, вдали от REST. Это облегчило бы мне интеграцию функций реального времени во все части сайта. Это сделало бы его более трудным построить приложения или мобильные клиенты?

Я обнаружил, что некоторые люди уже делают такое: SocketStream

81
javascript node.js rest websocket

8 ответов

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

Я серьезно рассматриваю возможность перемещения моего приложения из Спокойной архитектуры в более стиль RPC через websockets. Это не "игрушечное приложение", и я не говорю только о функциях в реальном времени, поэтому у меня есть оговорки. Но я вижу много преимуществ идя по этому маршруту и чувствуя, что это может оказаться исключительным решением.

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

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

Мне было бы интересно следить за вашим прогрессом в изучении этого типа решения. Если у вас есть эксперименты github, пожалуйста, укажите мне на них. Пока нет, но надеюсь скоро.

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

отличный учебник по использованию сокета.IO с Express. Он предоставляет экспресс-сеансы сокету.io и обсуждает, как иметь разные комнаты для каждой аутентификации пользователь.

самоучитель по узлу.с JS/гнездо.Ио/позвоночник.с JS/экспресс/подключения/Джейд/Redis с проверкой подлинности, Joyent таких, и т. д.:

учебник по использованию толкателя с позвоночником.js (использование Rails):

построить приложение с позвоночником.js на клиенте и узле.js с express, сокет.io, dnode на сервер.

используя Позвоночник с DNode:

84

HTTP REST и WebSockets очень разные. HTTP-это , поэтому веб-серверу ничего не нужно знать, и вы получаете кэширование в веб-браузере и прокси. Если вы используете WebSockets, ваш сервер становится stateful и вам нужно иметь соединение с клиентом на сервере.

запрос-ответная связь vs Push

использовать WebSockets, только если вам нужно PUSH данные с сервера на клиент, что шаблон связи не включен в HTTP (только обходными путями). PUSH полезен, если события, созданные другими клиентами, должны быть доступны другим подключенным клиентам, например, в играх, где пользователи должны действовать на поведение других клиентов. Или, если ваш сайт что-то отслеживает, где сервер постоянно передает данные клиенту, например, фондовые рынки (live).

Если вам не нужно толкать данные с сервера, обычно проще использовать HTTP REST без состояния сервер. HTTP использует простой Запрос-Ответ шаблон общения.

45

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

нет. Вы не должны этого делать. Нет никакого вреда, если вы поддерживаете обе модели. Использовать остальное для односторонней связи / простых запросов&WebSocket для двусторонней связи, особенно когда сервер хочет послать уведомление в режиме реального времени.

WebSocket является более эффективным протоколом, чем RESTful HTTP но все равно RESTful HTTP результаты по WebSocket в ниже областях.

  1. ресурсы Create/Update / Delete хорошо определены для HTTP. Вы должны осуществить эти операции на низком уровне для WebSockets.

  2. соединения WebSocket масштабируются вертикально на одном сервере, где как HTTP-соединения масштабируются горизонтально. Существуют некоторые собственные нестандартные решения для горизонтального масштабирования WebSocket .

  3. HTTP поставляется с множеством хороших функций, таких как кэширование, маршрутизация, мультиплексирование, gzipping и т. д. Они должны быть построены поверх Websocket, если вы выбрали Websocket.

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

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

  6. безопасность с WebSocket-это подход "все или ничего".

посмотри статьи для получения более подробной информации.

25

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

поэтому вы не можете учиться на ошибках других людей и развитие будет медленнее. Это также не" проверенная и проверенная " стратегия.

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

помните, что HTTP-это абстракция для TCP, предназначенная для обслуживания веб-контента.

и давайте не будем забывать, что SEO и поисковые системы не делают websockets. Таким образом, вы можете забыть о SEO.

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

не используйте WS для обслуживания веб-сайтов, используйте его для обслуживания веб-приложений

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

12

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

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

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

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

3) HTML и Javascript. Они включают пользовательский интерфейс webapp. Они, как правило, выиграют от размещения на CDN.

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

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

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

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

2

хочу ли я получать обновления с сервера?

  • Да: Гнездо.Ио
  • нет: остальные

недостатки сокета.io являются:

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

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

2

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

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

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

1

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

-1