Seedance API: как проверить параметры на тестовой задаче

Практические особенности сценария

Начните с опубликованного каталога RussiaAPI и фиксируйте дату проверки. Выпишите маршрут, разрешённые model ID, обязательные поля, лимиты размера, ожидаемый тип ответа и способ получения статуса. Не берите параметры из чужого SDK, рекламного скриншота или прошлой версии приложения. Если поле не документировано для вашего сценария, не включайте его в генератор клиента и не утверждайте, что оно поддерживается.

Соберите минимальную синтетическую задачу: короткое нейтральное описание, разрешённое соотношение сторон и только необходимые параметры. Не загружайте тестовые фотографии людей, материалы клиентов или чужой контент. Server-side adapter добавляет ключ из окружения, а код браузера и логи никогда не видят его. Ответ сохраните как обезличенный fixture: без credential, URL с временным доступом или содержимого, которое не нужно для контракта.

Проверяйте отдельно принятие запроса и жизненный цикл задачи. Создание может вернуть operation_id, а итоговый статус появляется позднее через polling или webhook — конкретная форма зависит от актуального контракта. Ваше приложение задаёт собственные состояния queued, processing, completed, failed и unknown, не подменяя ими реальные поля поставщика. Это упрощает смену адаптера и не заставляет интерфейс обещать время выполнения.

Зафиксируйте контрактный тест: обязательные поля должны быть приняты, неизвестное поле отклонено или проигнорировано предсказуемо, а ответ проходит schema-валидацию. Добавьте негативные случаи: пустое описание, слишком большой вход, отсутствие прав, несуществующий model ID и повтор операции. Тест не должен требовать настоящего ключа в репозитории; CI использует test secret и маскирует любые diagnostic headers.

Выпускайте новую версию параметров через feature flag и небольшой tenant. Наблюдайте безопасные метрики: класс ошибок, длительность, статус, долю невалидных ответов и количество отмен. При расхождении с ожиданием отключите новый путь и сохраните version/request_id для расследования. Нельзя переносить единичный успешный тест в обещание стабильности, доступности модели или сохранности результата.

Короткий ответ и граница сценария

Для тестовой видео-задачи используйте один server-side adapter, собственный request_id и явную политику приложения. Не переносите в клиент ключ, URL внешнего поставщика, model ID или право принимать решение. Seedance в этой статье — название поискового сценария; фактические возможности RussiaAPI, поля и доступ проверяют перед запуском.

Сначала опишите, что приложение делает при успехе, отказе, временной недоступности и неизвестном статусе. Такой контракт делает интерфейс предсказуемым и оставляет место для изменения внешней интеграции. Он не обещает, что поставщик примет запрос, сохранит результат или даст одинаковый ответ завтра.

Проверяйте вход на сервере

Клиент может передать неполные, ошибочные или намеренно изменённые данные. Поэтому backend получает аутентификацию и tenant из своей сессии, ограничивает тип, размер и допустимые поля, а затем формирует минимальный запрос для тестовой видео-задачи. Секрет хранится только в окружении server-side процесса.

Не логируйте исходный материал, ключ, cookie, Authorization или полный ответ внешней системы. Для поддержки обычно достаточно request_id, tenant, размера, времени, версии adapter и безопасного класса результата. Доступ к этим данным отделяйте от права пользователя запускать операцию.

Версионируйте контракт и тесты

Сохраните версию правила, схему запроса и дату сверки с текущей документацией. Новое обязательное поле, изменение статуса или model ID сначала проверяйте на test tenant. Fixture должен быть синтетическим и обезличенным; в репозиторий не попадают реальные файлы, credentials или временные ссылки.

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

Состояния, повторы и отмена

Отделяйте принятие запроса от завершения тестовой видео-задачи. Внутренние состояния queued, processing, completed, failed и unknown помогают показать честный статус, даже если внешний API меняет названия полей. Не транслируйте наружу сырой текст ошибки или конфигурацию адаптера.

Повтор ограничивают по времени и числу попыток. Перед новым действием сервер проверяет предыдущий operation_id, потому что timeout не доказывает отсутствие побочного эффекта. Если документированный контракт не подтверждает идемпотентность, новый запуск рассматривается как отдельное действие и требует безопасной политики.

Наблюдаемость без лишних данных

Измеряйте только то, что помогает управлять качеством workflow: класс ошибки, длительность, количество отмен, долю неизвестных статусов и повторов. Связывайте данные с request_id, а не с содержимым материала. Метрики не публикуйте как обещание SLA, доступности или точности.

Перед production включайте feature flag для малого test tenant и заранее определяйте условие отката. При аномалии выключите маршрут, сохраните минимальную техническую трассу и вернитесь к контролируемому ручному процессу. Это безопаснее, чем скрыто менять параметры или бесконечно повторять запросы.

Server-side пример

Пример показывает локальную проверку на сервере. Ключи берутся только из окружения; перед запуском подтвердите маршрут, model ID и параметры в актуальном каталоге RussiaAPI.

export function validateVideoRequest(input) {
  const allowed = new Set(['model', 'prompt', 'aspect_ratio']);
  if (!input || Object.keys(input).some((k) => !allowed.has(k))) throw new Error('unknown_field');
  if (typeof input.prompt !== 'string' || input.prompt.trim().length < 3 || input.prompt.length > 800) throw new Error('invalid_prompt');
  return { model: input.model, prompt: input.prompt.trim(), aspect_ratio: input.aspect_ratio ?? '16:9' };
}
// Call only a currently documented server-side route; do not embed credentials.

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