Использование блокировки запросов REST для внедрения публикации/подписки

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

Я указал, что REST - это протокол запроса/ответа, и они делают публикацию/подписку. Решение, которое они предлагали, заключалось в том, чтобы сделать запрос HTTP REST, который блокирует, а затем в конечном итоге будет реагировать, если и когда событие было доступно - или тайм-аут.

В любом случае будет сделан еще один запрос, чтобы получить следующее событие и так далее до бесконечности.

Эта идея заставила меня съежиться, но я был уверен, что iPhone "push" электронной почты работает таким образом.

Это разумное использование REST?

Ответ 1

Я бы сказал, что он плохо справляется с архитектурным стилем REST (главным образом потому, что REST ограничивает его взаимодействием с сервером без состояния). Тем не менее, сеть изобилует решениями, которые делают длинный опрос, и он работает более или менее, несмотря на то, что он не находится в духе Интернета.

Во-первых, примечание об архитектуре: реализация pub/sub в REST просто означает, что издатель добавляет элементы в список, который затем становится доступным для подписчиков. Подписчики опросили список. Есть способы сделать это, чтобы обеспечить один раз и только один раз, сохраняя при этом порядок сообщений и (форму) гарантированной доставки, хотя и асинхронно. Он очень хорошо масштабируется и действительно устойчив.

Мой первый совет - сделать его необязательным, чтобы клиенты, которые не могут выполнять длительный опрос (или не хотят), могут это сделать. Я даже зашел так далеко, чтобы сказать, что если общий клиент (например, Google) по умолчанию не будет выполнять длительный опрос, и что сервер проводит длинный опрос посредством специального общего понимания между вашим клиентом и сервером, Это совместное понимание может быть настраиваемым типом мультимедиа или настраиваемым связующим звеном или даже настраиваемым HTTP-заголовком, о котором не знали бы общие клиенты. Клиенты, которые поддерживают ваш длительный опрос, будут закодированы до для обнаружения возможностей длительного опроса и при необходимости вызовите его, возвращаясь к регулярному опросу, если длинный опрос завершится неудачно (например, посредник блокирует его каким-то образом).

И вместо того, чтобы пытаться сделать это поверх HTTP, я бы предложил использовать для этого не-HTTP-сокет, чтобы не нарушать намерения HTTP и эффективно использовать HTTP в качестве транспортного протокола. См. Cometd.

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