Как спроектировать RESTful HTTP-шлюз для протокола, который требует постоянных соединений? - PullRequest
Новая
       8

Как спроектировать RESTful HTTP-шлюз для протокола, который требует постоянных соединений?

6 голосов
/ 11 июля 2010

Я работаю с постоянным протоколом клиент / сервер, и мне нужно спроектировать шлюз RESTful. У меня нет большого опыта разработки REST-интерфейсов, и я не понимаю, как мне следует обрабатывать (RESTful) идентификаторы сеансов, необходимые для поддержания постоянных соединений на сервере, и как я должен представлять состояние сервера как ресурсы.

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

Конкретный контекст проблемы: я хочу улучшить существующий шлюз ZooKeeper REST для поддержки эфемерных узлов и часов. Эфемерный узел существует, пока клиент подключен к серверу.

Спасибо.

1 Ответ

4 голосов
/ 11 июля 2010

То, как я делал это в прошлом, следует шаблону «билет» или «квитанция».Служба REST принимает запросы на ресурс (имя отчета, znode и т. Д.) И возвращает тикет.Этот билет (обычно UUID или что-то подобное) может использоваться для представления сеанса.Последующие запросы используют этот тикет для проверки статуса их запросов.Для обеспечения правильного истечения срока действия билетов происходит один из двух случаев;Вы можете тайм-аут билеты или, после получения результата, клиент должен предоставить ACK (подтверждение) обратно к услуге.

ex.

Запрос: GET / zookeeper / znode / ephemeral /foo Ответ: 1234-1234-1234-1234

Запрос: GET / zookeeper / status / 1234-1234-1234-1234 Ответ: РАБОТАЮЩИЙ (или НЕ ДОСТУПЕН, или ЗАБЛОКИРОВАН, НЕТГОДНО или НЕ УДАЛЕН ...)

Запрос: GET / zookeeper / status / 1234-1234-1234-1234 Ответ: ПРИОБРЕТЕН (или ДОСТУПЕН, или ОК, или УСПЕХ, или какое-либо значение (я) ...)

Запрос: GET / zookeeper /Подтверждение / 1234-1234-1234-1234 Ответ: ОК (или НЕИЗВЕСТНЫЙ БИЛЕТ и т. д.)

Интересные сообщения об управляемости:

Запрос: GET / zookeeper / session (или / tickets) Ответ:[1234, 5668, ...]

Запрос: GET / zookeeper / kill / Response: OK (или UNKNOWN или FAILED ...)

Это сработало очень и очень хорошо.Это означает, однако, что служба REST находится в состоянии, что усложняет балансировку нагрузки.Я использовал протокол, который гарантирует, что идентификатор сервера возвращается при каждом ответе, и если клиент получает другой идентификатор сервера и НЕИЗВЕСТНЫЙ билет, вы предполагаете, что служба, с которой вы разговаривали, умерла и начала работу заново.Это подразумевает липкую балансировку нагрузки (то есть циклический перебор не будет работать здесь).Служба REST должна быть многопоточной, чтобы поддерживать выполнение этих запросов параллельно и обеспечивать доступ к базе данных заявок (обычно в памяти, структуре данных хэш-таблицы синхронизации), а также к потоку тайм-аута сеанса / билета.

Надеюсь, это поможет.

...