Как Socket.io и RESTFul работают вместе?

(Я не знаком с RESTFul, пожалуйста, поправьте меня, если моя концепция неверна)

В архитектуре RESTFul мы сопоставляем каждое действие с URL-адресом. Если я нажму "опубликовать статью", это может быть на самом деле URL http://example.com/ и некоторые данные action=post&content=blahblah.

Если я хочу опубликовать, но не обновить всю веб-страницу, я могу использовать javascript XMLHTTPRequest. Я отправляю его, а затем получаю его содержимое и вставляю его в div на моей странице. Эти действия являются асинхронными.

Тогда я знаю, что есть что-то с именем WebSocket и оно обертка socket.io. Он использует "сообщение" для связи между клиентом и сервером. Когда я нажимаю "post", клиент просто вызывает socket.send(data) и ждет сервер client.send(data). Это волшебство. Но как насчет URL?

Можно ли использовать две модели без повторения? Другими словами, каждое действие имеет URL-адрес, и некоторые из них могут взаимодействовать с пользователем в режиме реального времени (через socket.io?)

Кроме того, должен ли я это сделать? В очень интерактивной веб-программе (например, в играх) RESTFul по-прежнему имеет смысл?

Ответы

Ответ 1

Вы определяете обработчик для действий, которые отображаются в REST поверх http. POST и GET обычно ссылаются на обновление и запрос по сущности. Нет абсолютно никакой причины, по которой вы не можете просто определить обработчик для общих версий этих операций CRUD, которые могут использоваться в обоих контекстах. Как я обычно это делаю, это ввести понятие "маршрут" в транспорт в реальном времени и сопоставить их с теми же обработчиками CRUD.

У вас есть сеанс, вы можете наложить тот же ACL и т.д.

 +---------------------------------+
 |                                 |
 |      BROWSER                    |
 |                                 |
 +--+--^-------------------+---^---+
    |  |                   |   |
    |  |                   |   |
 +--v--+---+            +--v---+---+
 |         |            |          |
 | HTTP    |            | SOCKET.IO|
 +--+---^--+            +--+---^---+
    |   |                  |   |
 +--v---+------------------v---+---+
 |                                 |
 |        ROUTING/PUBSUB           |
 +-+--^-------+--^-------+--^------+
   |  |       |  |       |  |
 +-v--+--+  +-v--+--+  +-v--+-+
 |       |  |       |  |      |
 | USERS |  | ITEMS |  |ETC   |
 +-------+  +-------+  +------+
     ENTITY CRUD HANDLERS

Ответ 2

I недавно опубликовал это в своем блоге:

Проектирование CRUD API для WebSockets

При построении Weld мы используем как REST, так и WebSockets (Socket.io). Три наблюдения в WebSockets:

  • Так как WebSockets являются такой свободной формой, вы можете назвать события так, как вы хотите, но в конечном итоге отладка будет невозможна.
  • У WebSockets нет формы запроса/ответа HTTP, поэтому иногда бывает сложно определить, откуда происходит событие или собирается.
  • Было бы неплохо, если бы WebSockets могли вписываться в существующую структуру MVC в приложении, предпочтительно используя те же контроллеры, что и REST API.

Мое решение:

  • У меня есть два файла маршрутизации на моем сервере: routes-rest.js и routes-sockets.js
  • Мои события выглядят следующим образом: "AppServer/user/create".
  • Я использую косые черты ( "/" ), чтобы события выглядели как пути маршрутизации.
  • Первой строкой является target (~ "имя хоста", если это действительно был путь).
  • Вторая строка - это модель.
  • Третья строка - это CRUD-глагол: т.е. создавать, читать, обновлять, удалять.