Skip to main content
Для запросов, которые занимают больше нескольких секунд, что типично для приложений ИИ, мы разработали систему очередей. Эта система предлагает вам детальный контроль для управления всплесками трафика, отмены запросов при необходимости и мониторинга статуса вашего запроса в очереди. Она также устраняет необходимость обработки длительных HTTP-запросов.

Конечные точки очереди

Вы можете получить доступ ко всем функциям очереди через следующие конечные точки: Например, чтобы отправить запрос с помощью curl и добавить его в очередь:
Вот пример ответа, включающий request_id:
Полезная нагрузка включает request_id и предоставляет URL-адреса для проверки статуса, отмены или получения ответа, что упрощает ваш рабочий процесс без дополнительной разработки конечных точек.

Статус запроса

Для отслеживания хода выполнения вашего запроса используйте предоставленную конечную точку с вашим уникальным идентификатором запроса. Это позволяет отслеживать статус, положение в очереди или получать ответ, как только он будет готов.

Использование конечной точки

Пример ответа

Когда ваш запрос находится в очереди, вы получите ответ, подобный этому:

Возможные статусы

Ваш запрос может находиться в одном из трех состояний:
  • IN_QUEUE: указывает, что запрос ожидает обработки.
    • queue_position: показывает ваше место в очереди.
    • response_url: URL-адрес для получения ответа после завершения обработки.
  • IN_PROGRESS: запрос в настоящее время обрабатывается.
    • logs: подробные журналы (если включены), показывающие этапы обработки.
    • response_url: где будет доступен окончательный ответ.
  • COMPLETED: обработка завершена.
    • logs: журналы с подробным описанием всего процесса.
    • response_url: прямая ссылка на ваш готовый ответ.

Включение журналов

Журналы предоставляют информацию об обработке запросов. По умолчанию они отключены, но их можно включить с помощью параметра запроса:
Каждая запись журнала включает:
  • message: описание события.
  • level: серьезность (например, INFO, ERROR).
  • source: источник журнала.
  • timestamp: время создания журнала.

Мониторинг в реальном времени

Для непрерывного обновления используйте потоковую конечную точку:
Это обеспечивает обновление статуса в реальном времени в формате text/event-stream до завершения запроса.

Webhooks

Если вы предпочитаете получать уведомления вместо опроса, передайте параметр запроса webhook при отправке запроса. Sunra отправит окончательный результат POST-запросом на этот URL, как только запрос достигнет конечного состояния, поэтому вам не нужно держать соединение открытым или планировать опрос.

Включение Webhooks

Добавьте URL-кодированный параметр запроса webhook к эндпоинту отправки:
URL-кодируйте URL webhook (например, https%3A%2F%2F...) и убедитесь, что Sunra может до него достучаться; настоятельно рекомендуется использовать HTTPS. Ответ на отправку остаётся неизменным — вы по-прежнему получаете request_id и те же URL для статуса/отмены/ответа.

Когда срабатывает Webhook

Sunra вызывает ваш webhook только при конечных событиях:
  • succeeded — запрос завершён, и вывод включён в полезную нагрузку.
  • failed — запрос завершился с ошибкой, и детали ошибки включены в полезную нагрузку.
Промежуточные состояния (IN_QUEUE, IN_PROGRESS) не вызывают webhook. Если вам также нужны обновления прогресса, используйте webhook вместе с эндпоинтами стриминга или опроса, описанными выше.

Формат запроса

Sunra отправляет POST-запрос на ваш URL webhook со следующими заголовками: Ваш эндпоинт должен ответить кодом статуса 2xx в течение 5 секунд. Подтвердите быстро и перенесите тяжёлую работу в фоновое задание — медленные ответы считаются неудачными и вызывают повторные попытки.

Полезная нагрузка

Успешное событие:
Неуспешное событие заменяет output на error. Точное содержимое error зависит от типа сбоя — пример ниже показывает одну из распространённых форм:

Поведение повторов

Доставка webhook осуществляется по принципу хотя бы один раз. Если ваш эндпоинт превышает таймаут (5 с) или возвращает не-2xx статус, Sunra повторяет с экспоненциальной задержкой — до 3 повторов с задержками от 10 секунд и не более 30 секунд. После последнего повтора сбой регистрируется, и больше попыток не предпринимается. Поскольку повторы могут доставлять одно и то же событие несколько раз, ваш обработчик должен быть идемпотентным — используйте поле id в качестве ключа дедупликации.

Лучшие практики

  • Используйте HTTPS и проверьте, что трафик доходит до ожидаемого эндпоинта.
  • Отвечайте 2xx немедленно и обрабатывайте полезную нагрузку асинхронно.
  • Считайте доставку доставкой хотя бы один раз и дедуплицируйте по id.
  • Объединяйте webhook с эндпоинтами опроса или стриминга, если вам нужны обновления прогресса до конечного события.

Отмена запросов

Если ваш запрос все еще находится в очереди, вы можете отменить его с помощью:

Получение ответов

Как только ваш запрос будет COMPLETED, получите ответ, используя:
Эта конечная точка также предоставляет журналы для просмотра.

Упрощенная интеграция с клиентом Sunra

Клиент Sunra автоматизирует отслеживание статуса, упрощая разработку приложений с функциями Sunra.

Ограничения скорости

Чтобы обеспечить справедливое использование и стабильность системы, наши конечные точки API подлежат следующим ограничениям скорости: Если вы превысите эти лимиты, вы получите ответ 403 Forbidden. Мы рекомендуем реализовать механизм повторных попыток с экспоненциальной задержкой для обработки таких случаев.