Как Socket.io и RESTFul могут работать вместе? - PullRequest
Новая
       5

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

31 голосов
/ 14 июня 2011

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

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

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

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

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

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

Ответы [ 2 ]

37 голосов
/ 16 июня 2011

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

 +---------------------------------+
 |                                 |
 |      BROWSER                    |
 |                                 |
 +--+--^-------------------+---^---+
    |  |                   |   |
    |  |                   |   |
 +--v--+---+            +--v---+---+
 |         |            |          |
 | HTTP    |            | SOCKET.IO|
 +--+---^--+            +--+---^---+
    |   |                  |   |
 +--v---+------------------v---+---+
 |                                 |
 |        ROUTING/PUBSUB           |
 +-+--^-------+--^-------+--^------+
   |  |       |  |       |  |
 +-v--+--+  +-v--+--+  +-v--+-+
 |       |  |       |  |      |
 | USERS |  | ITEMS |  |ETC   |
 +-------+  +-------+  +------+
     ENTITY CRUD HANDLERS
29 голосов
/ 16 февраля 2014

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

Разработка CRUD API для WebSockets

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

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

Мое решение:

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