Как разработать УСПОКОИТЕЛЬНЫЙ шлюз HTTP для протокола, который требует постоянных соединений?
Я работаю с персистентным клиент-серверным протоколом, и я должен разработать УСПОКОИТЕЛЬНЫЙ шлюз. У меня нет большого опыта, разрабатывая интерфейсы REST, и я не понимаю, как я должен обработать (УСПОКОИТЕЛЬНЫМ способом), идентификаторы сессии должны были поддержать постоянные соединения на сервере и как я должен представить состояние сервера как ресурсы.
Я спрашиваю это, потому что я не хочу заканчивать с результатом выхода RPC, который выглядит "УСПОКОИТЕЛЬНЫМ".
Проблема определенный контекст: Я хочу улучшить существующий шлюз ZooKeeper REST для поддержки эфемерных узлов и часов. Эфемерный узел существует, в то время как клиент подключен к серверу.
Спасибо.
1 ответ
Способ, которым я делал это в прошлом, соответствует шаблону "билет" или "квитанция". Служба REST принимает запросы на ресурс (имя отчета, znode и т.д.) и возвращает тикет. Этот билет (обычно UUID или что-то подобное) может использоваться для представления сессии. Последующие запросы используют этот билет для проверки состояния своих запросов. Чтобы обеспечить надлежащее истечение срока действия билетов, происходит один из двух случаев; можно установить тайм-аут билетов или, получив результат, клиент должен предоставить ACK (подтверждение) обратно сервису.
ex.
Запрос: GET /zookeeper/znode/ephemeral/foo Ответ: 1234-1234-1234-1234
Request: GET /zookeeper/status/1234-1234-1234-1234 Ответ: РАБОТАЕТ (или UNAVAILABLE или BLOCKED или NOTREADY или FAILED...)
Запрос: GET /zookeeper/status/1234-1234-1234-1234 Ответ: ACQUIRED (или AVAILABLE или OK или SUCCESS или некоторое значение(я)...)
Запрос: GET /zookeeper/acknowledge/1234-1234-1234-1234 Ответ: OK (или UNKNOWN TICKET, и т.д.)
Интересные сообщения об управляемости:
Запрос: GET /zookeeper/sessions (или /tickets) Ответ: [ 1234, 5668, ... ]
Запрос: GET /zookeeper/kill/ Ответ: OK (или UNKNOWN или FAILED...)
Это работает очень, очень хорошо. Однако это означает, что REST-сервис является государственным, что делает такие вещи, как балансировка нагрузки, более сложными. Я использовал протокол, который гарантирует, что ID сервера возвращается с каждым ответом, и если клиент получает другой ID сервера и билет UNKNOWN, вы считаете, что сервис, с которым вы разговаривали, умер, и начинаете сначала. Это подразумевает "липкую" балансировку нагрузки (т.е. round-robin здесь не подойдет). REST-сервис должен быть многопоточным, чтобы поддерживать параллельное выполнение этих запросов и обеспечивать доступ к базе данных билетов (обычно в памяти, синхронизируемая структура данных hashtable), а также к потоку тайм-аута сессии/билета.
Надеюсь, это поможет.