Возможно ли использование ПОРТ через websockets?

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

Использование веб-интерфейсов для такого типа приложений на основе чата выглядело многообещающим, поскольку события (или ответы) могут быть поставлены асинхронно. Но если я использую websockets в качестве основного протокола для передачи запросов из браузера, может ли это быть рассмотрен как проект ReSTful? Если да, то как URI, глаголы (GET, POST...), параметры представлены в сообщении websocket? Оберните их в xml/json и отправьте его?

Кроме того, архитектура ReSTful заявляет, что на сервере не будет сохранено состояние сеанса. Но здесь, в этом случае, когда создается клиентский сеанс XMPP, состояние этого сеанса будет храниться на сервере (нарушая ограничение без сохранения)

Ответ 1

Почему вы хотите создать REST API поверх сокета? IMHO преимущество REST API заключается в использовании стандартных возможностей протокола HTTP, таких как запросы без учета состояния, семантические глаголы, такие как GET, DELETE для создания API, который может быть легко понят разработчиками (клиентом). Поскольку сокеты не предлагают HTTP-глаголы и т.д., Вы бы создали какой-то HTTP-уровень для сокетов, который IMHO не является разумным.

Если бы вы действительно создали такую вещь, я бы рекомендовал использовать протокол HTTP в качестве плана и реализовать протокол сокета, например HTTP.

Ответ 2

REST - это архитектурный стиль, который не налагает протокол. Так что да, вы можете сделать REST с помощью веб-сокетов, REST с HTTP и REST с FTP, если хотите.

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

Мой наряд: Если вы являетесь исследователем RESTliban и Рой Филдинг, источником истины, глаголы никогда не признаются частью семантики. URI являются семантикой. Использование разных глаголов для разных действий было изящной эволюцией REST над HTTP, но не частью "истины". Вы можете проверить сценарий отдыха над HTTP, оцененный Роем в шестой главе своей диссертации. Никаких упоминаний о глаголах. И обратите внимание, что это сценарий оценки, а не спецификация.

TL;DR;

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

Ответ 3

Да. Вы можете использовать REST поверх WebSocket с библиотекой, например SwaggerSocket.

Ответ 4

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

Есть библиотеки JavaScript, которые могут говорить XMPP из браузера на сервер. Все, что вам нужно, - проксировать трафик XMPP с WS поверх TCP, а затем прямо на ваш сервер XMPP. У Kaazing есть шлюз, который позволяет вам это делать.

Если вы хотите использовать открытый исходный код, вам нужно будет написать библиотеку JavaScript XMPP. Есть примеры, которые показывают, как писать JS-библиотеку для простых протоколов. Вам просто нужно найти его и расширить концепцию до протокола XMPP.

Итак, чтобы понять, вот как выглядит архитектура:

Ваш код клиента XMPP ↔ Библиотека JavaScript XMPP ↔ WebSocket через http ↔ WebSocket to TCP Proxy ↔ Сервер XMPP

где в браузере запущен клиентский код XMPP и библиотека JavaScript XMPP, а прокси-сервер WS-TCP и сервер XMPP - серверные.

Ответ 5

Архитектурный стиль REST в основном предполагает наличие двух объектов: клиента и сервера.

По мере того, как мы больше движемся к сети реального времени и разрабатываем реактивные системы, WebSocket заметно начнет заменять использование API REST.

WS позволяет передавать данные push и pull, что отклоняет концепцию сервера и клиента.

STOMP, AMQP, XMPP могут использоваться как протоколы обмена сообщениями.

Сами данные могут быть JSON или буферами протокола Google или, возможно, Apache Avro.

WebSockets не привязан к веб-серверам, но может быть разработан в автономных приложениях, таких как мобильные приложения или настольные приложения.

Ответ 6

Я просто задаю новую тему в блоге одной компании, которая предоставляет облачные решения и "Сервер-конец/Сервис как платформа" (SaaS) для игр.

Я не рекламирую эту компанию, и не использовал ее, поэтому я даже не знаю, насколько они хороши или плохи.

Однако они очень четко объясняют причины и каковы преимущества использования WebSockets в REST Прочитайте свой блог

Ответ 7

Я понимаю, что это сообщение действительно старое, но хотелось немного вставить в понятие "что, если я выберу архитектуру REST, я потеряю способность к обмену в реальном времени?".

Одним словом, нет. Ряд реализаций стиля REST у меня был опыт использования REST для совместимости, обнаружения и как средство масштабирования на разных устройствах в тени IoT.

Однако, помимо использования WS в дополнение к REST для облегчения передачи в реальном времени. Существует также ряд абстракций, которые действительно помогают в этом, и позволяют сосредоточиться на создании вашего API и решении о том, как должны работать компоненты RT потребляющих приложений.

Я бы предложил взглянуть на такие вещи, как Tibco Smart-Sockets или SignalR, если вы хотите создать REST API и хотите избежать повторного создания колеса для ваших потребностей RT.