API-интерфейс Websocket для замены REST API?

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

Учебное пособие по node.js/socket.io/backbone.js/express/connect/jade/redis с аутентификацией, хором хостинга и т.д.:

Учебник по использованию Pusher с Backbone.js(с использованием Rails):

Создайте приложение с backbone.js на клиенте и node.js с помощью express, socket.io, dnode на сервере.

Использование магистрали с DNode:

Ответ 2

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

Связь с запросом и ответом vs Push

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

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

Ответ 3

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

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

WebSocket - более эффективный протокол, чем RESTful HTTP, но все еще RESTful HTTP оценивает WebSocket в нижележащих областях.

  • Создать/обновить/удалить ресурсы были хорошо определены для HTTP. Вы должны выполнить эти операции на низком уровне для WebSockets.

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

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

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

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

  • Безопасность с помощью WebSocket - это подход "все или ничего".

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

Ответ 4

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

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

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

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

И не забывайте, что SEO и поисковые системы не занимаются веб-сайтами. Поэтому вы можете забыть о SEO.

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

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

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

Ответ 5

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

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

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

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

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

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

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

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

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

Ответ 6

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

  • Да: Socket.io
  • Нет: REST

Недопустимыми для Socket.io являются:

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Сказав все это, честно говоря, я думаю, что мы упустили некоторые отличные функции сокета-ввода. Socket-io может предложить гораздо больше, и я уверен, что если вы примете это во внимание в своем первоначальном дизайне, вы сможете извлечь из этого больше пользы. Напротив, мы просто заменили старые веб-сокеты на функциональность веб-сокетов в Socket-Io, и это было все. (нет комнат, нет каналов,...) Редизайн мог бы сделать все более мощным. Но у нас не было времени на это. Это то, что нужно запомнить для нашего следующего проекта.

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

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

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

Ответ 9

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