Сервер RESTful и использование socket.io противоречивы?

Question

Я разрабатываю сервер node/express RESTful с обычными маршрутами и HTTP-запросом и ответом. Теперь меня просят расширить сервер, чтобы предоставлять данные в реальном времени клиентам, использующим socket.io или некоторые такие вещи.

Я чувствую, что для обновления в реальном времени требуется клиент и обслуживание управления соединением и управление состоянием клиента на сервере, и это само по себе является ортогональным аспектам RESTful моего сервера. Для клиента, чтобы получить непрерывную передачу данных с сервера RESTful, клиент должен «опросить» его.

Является ли мое заявление правильным? Если нет, есть ли образец для предоставления двух функций?

Answer 1

Правильные, RESTful-сервисы противоречат клиентскому/серверному соединению с состоянием, необходимым для ввода/вывода в реальном времени. Не зная, сколько данных ваш разговор о RESTful будет очень дорогим в I/O.

Answer 2

Нет, нет никаких противоречий. Каждый HTTP-запрос выполняет обратную связь с настройкой и многое другое, если вы поддерживаете SSL (что вам нужно) или выполняете большинство форм аутентификации. Socket.io позволяет свести к минимуму эти настройки, оставив соединение открытым и аутентифицированным, готовым к следующему запросу. Вы могли бы что-то сделать с заголовком 100 Continue, следуя разделу 8.2.3 спецификации: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Но, просто выполняя обычные запросы RETful https по запросу socket.io, следует показать значимое снижение латентности, минимизируя необходимость для восстановления соединений. Конечно, реализация полной поддержки push-сервера еще более снизит латентность.

Компромисс повышенной сложности (хотя socket.io может быть реализован в Express в нескольких строках), а также увеличилось потребление памяти, оставив сокеты открытыми.