В последние годы веб-приложения испытали большой сдвиг в парадигме.
Десять лет назад (и, к сожалению, даже в наши дни) веб-приложения жили только в супертяжелых серверах, обрабатывая все от форматов данных до презентаций и отправляя немым клиентам, которые только отображали вывод сервера (браузеров).
Затем AJAX присоединился к игре, и веб-приложения начали превращаться во что-то, что жило между сервером и браузером.
В эпоху AJAX логика веб-приложений начала полностью жить в браузере. Я думаю, что это было когда HTTP RESTful API начал появляться. Внезапно каждая новая служба имела свой вид RESTful API, и вдруг фреймворки JavaScript MV * начали появляться, как попкорны. Использование мобильных устройств также значительно увеличилось, и REST идеально подходит для подобных сценариев. Я говорю "вид RESTful" здесь, потому что почти каждый API, который утверждает, что является REST, не является. Но это совсем другая история.
Фактически, я стал своего рода "евангелистом REST".
Когда я думал, что веб-приложения не могут развиваться намного больше, новая эра, похоже, зарождается: постоянные веб-приложения с постоянным подключением. Meteor является примером блестящей структуры такого рода приложений. Затем я увидел этот видео. В этом видео Мэтт Дебергалис рассказывает о Метеор, и оба делают фантастическую работу! Однако он как бы сводит REST API для таких целей в пользу постоянных подключений в реальном времени.
Я бы очень хотел иметь обновления модели в режиме реального времени, например, но все еще обладаю всей привлекательностью REST. Потоковое REST API похоже на то, что мне нужно (firehose.io и Twitter API, например), но информации об этом новом виде API очень мало.
Итак, мой вопрос:
Является ли веб-связь в режиме реального времени несовместимой с парадигмой REST?
(Извините за длинный вводный текст, но я думал, что этот вопрос будет иметь смысл только в каком-то контексте)