На этой странице описаны различные рекомендации, которые следует учитывать при разработке приложений с использованием API Google Ad Manager.
- Повторное использование клиентов/заглушек службы в ходе выполнения.
- Используйте пейджинг при извлечении объектов
- Пакетные запросы на обновление
- При необходимости сохраните клиентский объект API Менеджера рекламы.
- Используйте параметры привязки в PQL
- Предоставляйте пользователям привилегии экономно
Повторное использование клиентов/заглушек службы в ходе выполнения.
Создание нового клиента/заглушки службы требует предельных затрат, связанных с получением WSDL и распределением ресурсов. Если возможно, создайте клиент/заглушку службы один раз в начале выполнения и сделайте его доступным для классов и функций по мере необходимости.
Используйте пейджинг при извлечении объектов
Все службы поддерживают метод get*ByStatement()
, который позволяет фильтровать результаты с использованием синтаксиса PQL . Предложения LIMIT
и OFFSET
можно использовать для разделения больших наборов результатов на страницы, предотвращая тайм-ауты и сохраняя разумные размеры страниц ответа. Рекомендуемый размер страницы — 200–500, в зависимости от сложности ваших объектов.
Пакетные запросы на обновление
При изменении нескольких объектов одного типа вы можете повысить производительность, отправив все объекты в одном запросе update*()
. Для каждого запроса на клиенте и сервере возникают незначительные накладные расходы, а пакетная обработка может быть эффективным средством сокращения количества запросов. Например, используйтеupdateOrders
для обновления пакета заказов , а не одного заказа в каждом вызове.
Используйте параметры привязки в PQL
Параметры привязки — это способ помещения переменных в оператор запроса PQL. PQL ссылается на переменную связывания по имени без пробелов, начинающемуся с двоеточия, например, :name
. Пример кода приведен на странице синтаксиса PQL .
Мы рекомендуем использовать переменные привязки, поскольку они улучшают читаемость кода, устраняя необходимость объединения строк и переменных в оператор запроса. Они также упрощают повторное использование операторов PQL, поскольку новые запросы можно создавать путем замены значений параметров привязки.
Предоставляйте пользователям привилегии экономно
При использовании UserService для создания/обновления пользовательских ролей будьте осторожны и не предоставляйте пользователям ненужные им привилегии. Доступ ко многим функциям API можно получить с помощью комбинации ролей, вместо того, чтобы назначать пользователю роль администратора. Пожалуйста, обратитесь к документации по разрешениям , когда решаете, какие роли назначить пользователю. Кроме того, будучи сторонним разработчиком приложений, обязательно определите, какой уровень доступа требуется вашему приложению, когда просите сеть создать для вас пользователя; роли с меньшими привилегиями, чем у администратора, может быть достаточно.
Оставайтесь в пределах квоты
API Менеджера рекламы применяет несколько ограничений квот для обеспечения надежности. Важно поддерживать эти ограничения в своих приложениях и знать, как реагировать на любые ошибки квот, которые может вернуть API.
API-квота
Первая квота, применяемая к запросам API, — это квота сетевого уровня. Для аккаунтов Менеджера рекламы 360 ограничение составляет 8 запросов в секунду, а для аккаунтов Менеджера рекламы — 2 запроса в секунду. Выход за пределы этого предела приводит к ошибке QuotaError.EXCEEDED_QUOTA
. Все запросы API, сделанные в вашей сети, применяются к этой квоте, включая сторонние приложения, которым вы или кто-то из вашей компании предоставил доступ API к вашей сети.
Системные квоты
Одной только квоты API недостаточно для адекватной защиты некоторых ресурсоемких систем Менеджера рекламы. Системы отчетности и прогнозирования определяют свои собственные квоты, которые могут привести к ошибкам API: QuotaError.REPORT_JOB_LIMIT
и ForecastError.EXCEEDED_QUOTA
соответственно.
Обработка ошибок квот
Если ваше приложение обнаруживает любую из вышеперечисленных ошибок квоты, примените стратегию повторной попытки запроса API. Мы рекомендуем сначала подождать не менее 5 секунд, а если ошибка продолжает возникать, используйте экспоненциальную отсрочку , чтобы увеличить время между повторными попытками. Если повторная попытка не увенчалась успехом, выполните аудит ваших приложений API, чтобы увидеть, не истощают ли какие-либо пользователи в вашей сети вашу квоту.