Разделите доступы и окружения
Создайте отдельный ключ для конкретного приложения и тестовой среды, назначьте владельца, срок пересмотра и минимально необходимые полномочия. Не встраивайте ключ в браузерный код и не храните его в открытом репозитории. Для проверки используйте отдельный проект или лимит, который не затрагивает бюджет production. Если ключ мог попасть в лог или скриншот, отзовите его и выпустите новый; удаление строки из последнего коммита не отменяет утечку.
Поставьте предел до первого запроса
Установите месячный или дневной бюджет, максимальное число вызовов на пользователя, ограничение размера входа и таймаут. Лимит расходов у провайдера может обновляться с задержкой, поэтому локальный счётчик запросов тоже нужен. Определите действие при достижении границы: остановить вызовы, перейти на ручную обработку или включить заранее проверенную альтернативу. Не разрешайте приложению бесконечно повторять запрос ради «успешного» ответа.
Обрабатывайте сбои разного типа по-разному
Таймаут, ограничение частоты, ошибка авторизации и некорректное содержимое требуют разных реакций. Повторять можно только временные ошибки, ограниченное число раз, с паузой и случайным интервалом. Для операций с побочным эффектом используйте idempotency key, если его поддерживает API, чтобы повтор не создавал два действия. Если запрос уже мог быть обработан, сначала выясните статус операции, а не посылайте её заново наугад.
Проверяйте ответ до потребителя
HTTP-успех ещё не означает, что модель вернула полезный результат. Проверьте тип, обязательные поля, допустимые значения и длину; неизвестные значения отправляйте на ручную проверку. Не передавайте ответ напрямую в платежи, внешнюю рассылку или запись клиента. Сохраните безопасный идентификатор запроса и код ошибки, но не полный текст персонального сообщения, если он не нужен для расследования.
Подготовьте наблюдаемость и выход
Считайте ошибки, задержку, расходы, частоту ручной проверки и число переходов на резерв. Проверьте сценарий отключения: кто выключает ключ, где видит очередь, как пользователь узнаёт о задержке и как возвращается накопленная работа. Обновления лимитов и схемы провайдера должны сопровождаться тестом. Для контроля изменений API пригодится карта изменений API; потребление ресурсов модели и инфраструктуры отдельно сравните в проверке ресурсов модели.
FAQ
**Нужен ли запасной провайдер?** Только если есть проверенный сценарий переключения и допустимо повторно передавать данные. Иначе безопасная остановка с ручной очередью лучше случайного автоматического fallback. **Где хранить ключ?** В менеджере секретов или защищённой серверной переменной, с ограниченным доступом и ротацией. **Можно ли повторять запрос при любой ошибке?** Нет. Повтор ограничивают по типу сбоя и числу попыток; для сомнительного результата запрос сначала сверяют по его идентификатору.
Короткая проверка
- Понятны цель и человек, который примет результат.
- Исходники очищены, их версия и дата сохранены.
- Факты, числа и ограничения сверены вручную.
- Неудачный пример записан вместе с причиной.
- Есть измеримый следующий шаг и путь назад.