Составь чек-лист интеграции с внешним API
Помогает подготовить безопасную интеграцию с внешним API: авторизацию, ошибки, retries, rate limits и логирование.
1 Готовый промпт
Выступи в роли разработчика, который готовит интеграцию с внешним API. Назначение: Отправка транзакционных уведомлений через внешнего провайдера.. Возможности API: REST API: отправка, статус, documented 429 и 5xx; поддерживается idempotency key.. Авторизация: Bearer token. Критичность: Высокая. Следуй структуре: 1. Проверь хранение и ротацию секретов. 2. Определи таймауты, retries и ошибки, которые нельзя повторять. 3. Учти rate limits и идемпотентность. 4. Опиши логирование без утечки секретов и персональных данных. 5. Продумай поведение при недоступности провайдера. 6. Добавь тестовую среду, моки, метрики и алерты. Не придумывай факты, данные, опыт или ограничения, которых нет во вводных. Если информации недостаточно, укажи, что нужно уточнить.
Как использовать
Заполните поля конструктора максимально конкретно. Чем точнее исходные данные, тем полезнее будет результат.
2 Настроить под себя
Заполните понятные поля ниже. Сервис автоматически соберёт новую версию промпта под вашу задачу.
3 Результат настройки
Заполните конструктор выше,
и здесь появится готовый промпт.
4 Примеры результата
Текстовый пример
1. Секреты Bearer token хранить вне кода и репозитория — через секреты окружения/секрет-хранилище. Нужно предусмотреть безопасную ротацию без остановки сервиса. 2. Таймауты и retries Для запросов задать ограниченный timeout. Повторять запросы при временных ошибках, например 429 и части 5xx, с задержкой между попытками. Ошибки клиента, которые не являются временными, повторять нельзя. Точные значения timeout и числа retries нужно уточнить. 3. Rate limits и идемпотентность Обрабатывать 429, учитывать указания провайдера о времени повторной попытки. Для отправки использовать idempotency key, чтобы retry не создавал дублирующее уведомление. 4. Логирование Логировать: тип операции; результат и HTTP-статус; время выполнения; идентификатор запроса. Не записывать Bearer token, содержимое чувствительных данных и персональные данные без необходимости. 5. Недоступность провайдера При временной недоступности не терять уведомление: предусмотреть механизм последующей повторной отправки. После исчерпания попыток переводить операцию в состояние ошибки для дальнейшей обработки. Конкретный механизм хранения очереди нужно определить отдельно. 6. Тестирование и мониторинг Нужны: тестовая среда или sandbox провайдера, если она существует; моки ответов 200, 429, 5xx, timeout; тесты идемпотентности и retries; метрики успешных/ошибочных отправок, latency и количества retry; алерты при росте ошибок или длительной недоступности API. Нужно уточнить: ограничения rate limit, правила Retry-After, доступность sandbox, SLA провайдера, допустимое время задержки уведомлений и требования к хранению неотправленных сообщений.
5 Комментарии
0