En mars 2022, nous avons lancé la version 2 de l'API Bid Manager. Compte tenu de la sortie de cette nouvelle version, nous prévoyons d'annoncer prochainement la date d'arrêt de la version 1.1. Nous vous recommandons de commencer votre migration de la version 1.1 vers la version 2 dès que possible.
Migrer votre application
Pour passer de la version 1.1 à la version 2, vous devez mettre à jour vos URL de point de terminaison pour appeler la version 2, ainsi que votre application pour tenir compte des modifications destructives.
Mettre à jour vos appels d'API de la version 1.1 à la version 2
Pour utiliser la version 2 au lieu de la version 1.1, vous devez mettre à jour vos requêtes afin qu'elles utilisent les nouveaux points de terminaison de la version 2.
Identifier les méthodes équivalentes
Pour faire passer vos appels d'API de la version 1.1 à la version 2, vous devez d'abord identifier les méthodes v1.1 équivalentes dans la version 2.
Les noms suivants de l'ensemble des services et méthodes ont légèrement changé entre les versions 1.1 et 2:
- Dans la version 2, les services
Queries
etReports
sont appelésqueries
etqueries.reports
. - Les méthodes ont été renommées comme suit dans la version 2:
Nom de la méthode v1.1 Méthode v2 équivalente Queries.createquery
queries.create
Queries.deletequery
queries.delete
Queries.getquery
queries.get
Queries.listqueries
queries.list
Queries.runquery
queries.run
Reports.listreports
queries.reports.list
Mise à jour vers les nouveaux points de terminaison
Une fois que vous avez identifié des méthodes équivalentes, vous devez mettre à jour vos requêtes. Par exemple, pour appeler la méthode queries.getquery
avec la version 1.1, vous devez utiliser l'URL suivante:
https://www.googleapis.com/doubleclickbidmanager/v1.1/query/queryId
Pour appeler la méthode équivalente dans la version 2, appelée queries.get
, modifiez l'URL comme suit:
GET https://doubleclickbidmanager.googleapis.com/v2/queries/queryId
Si vous utilisez une bibliothèque cliente pour envoyer des requêtes à l'API, utilisez la version la plus récente de cette bibliothèque et mettez à jour votre configuration pour qu'elle utilise la version 2.
Apporter les modifications requises
Nous apportons un certain nombre de modifications destructives dans la version 2. Consultez les instructions suivantes et apportez les modifications nécessaires en fonction de votre utilisation actuelle de l'API Bid Manager.
Mettre à jour les appels au service queries
- Les champs suivants de la ressource
Query
représentés à l'origine par des objets imbriqués généraux ont été modifiés pour utiliser les types d'objets suivants: - Les champs suivants de la ressource
Query
représentés à l'origine par des objets de liste générale ont été remplacés par des listes des nouveaux types d'objets suivants: - Les champs suivants de la ressource
Query
, représentés à l'origine par des chaînes, sont représentés par des types d'énumération dans la version 2 et incluent les modifications suivantes :- L'équivalent v2 de
metadata.dataRange
utilise désormais l'énumérationRange
. Lors de la conversion vers cette énumération, la valeurPREVIOUS_HALF_MONTH
a été supprimée et la valeurTYPE_NOT_SUPPORTED
a été remplacée parRANGE_UNSPECIFIED
. metadata.format
utilise désormais l'énumérationFormat
. Lors de la conversion vers cette énumération, la valeurEXCEL_CSV
a été supprimée et la valeurFORMAT_UNSPECIFIED
a été ajoutée.params.options.pathQueryOptions.channelGrouping.rules[].disjunctiveMatchStatements[].eventFilters[].dimensionFilter.match
etparams.options.pathQueryOptions.pathFilters[].eventFilters[].dimensionFilter.match
utilisent désormais l'énumérationMatch
.params.options.pathQueryOptions.pathFilters[].pathMatchPosition
utilise désormais l'énumérationPathMatchPosition
. Lors de la conversion vers cette énumération, la valeurPATH_MATCH_POSITION_UNSPECIFIED
a été ajoutée.schedule.frequency
utilise désormais l'énumérationFrequency
. Lors de la conversion vers cette énumération, la valeurFREQUENCY_UNSPECIFIED
a été ajoutée.params.type
utilise désormais l'énumérationReportType
. La conversion vers cette énumération a permis d'apporter les modifications suivantes:- Les valeurs suivantes ont été abandonnées :
TYPE_ACTIVE_GRP
TYPE_AUDIENCE_PERFORMANCE
TYPE_CLIENT_SAFE
TYPE_COMSCORE_VCE
TYPE_CROSS_FEE
TYPE_CROSS_PARTNER
TYPE_CROSS_PARTNER_THIRD_PARTY_DATA_PROVIDER
TYPE_ESTIMATED_CONVERSION
TYPE_FEE
TYPE_KEYWORD
TYPE_LINEAR_TV_SEARCH_LIFT
TYPE_NIELSEN_AUDIENCE_PROFILE
TYPE_NIELSEN_DAILY_REACH_BUILD
TYPE_NIELSEN_ONLINE_GLOBAL_MARKET
TYPE_PAGE_CATEGORY
TYPE_PETRA_NIELSEN_DAILY_REACH_BUILD
TYPE_PETRA_NIELSEN_ONLINE_GLOBAL_MARKET
TYPE_PIXEL_LOAD
TYPE_THIRD_PARTY_DATA_PROVIDER
TYPE_TRUEVIEW_IAR
TYPE_VERIFICATION
TYPE_YOUTUBE_VERTICAL
- Les valeurs restantes ont toutes été mises à jour pour mieux refléter leurs valeurs équivalentes dans l'interface utilisateur:
Valeurs v1.1 Valeur ReportType
équivalenteTYPE_NOT_SUPPORTED
REPORT_TYPE_UNSPECIFIED
TYPE_GENERAL
STANDARD
TYPE_INVENTORY_AVAILABILITY
INVENTORY_AVAILABILITY
TYPE_AUDIENCE_COMPOSITION
AUDIENCE_COMPOSITION
TYPE_ORDER_ID
FLOODLIGHT
TYPE_TRUEVIEW
YOUTUBE
TYPE_NIELSEN_SITE
GRP
TYPE_PETRA_NIELSEN_AUDIENCE_PROFILE
YOUTUBE_PROGRAMMATIC_GUARANTEED
TYPE_REACH_AND_FREQUENCY
REACH
TYPE_REACH_AUDIENCE
UNIQUE_REACH_AUDIENCE
TYPE_PATH
FULL_PATH
TYPE_PATH_ATTRIBUTION
PATH_ATTRIBUTION
- L'équivalent v2 de
- Les champs
metadata.dataRange
,reportDataStartTimeMs
etreportDataEndTimeMs
ont été remplacés par les champsrange
,customStartDate
etcustomEndDate
. Les nouveaux champs de date utilisent des objetsDate
au lieu de millisecondes depuis l'epoch Unix. Ces champs de remplacement ont été déplacés vers l'objetDataRange
attribué au champdataRange
dans l'objetQueryMetadata
. - Les champs
schedule.startTimeMs
etschedule.endTimeMs
ont été remplacés par les champsstartDate
etendDate
dans l'objetQuerySchedule
. Les nouveaux champs de date utilisent des objetsDate
au lieu de millisecondes depuis l'epoch Unix. - Les champs
metadata.running
,metadata.reportCount
,metadata.googleCloudStoragePathForLatestReport
,metadata.googleDrivePathForLatestReport
etmetadata.latestReportRunTimeMs
ont été supprimés. Les informations concernant les rapports les plus récents générés pour une requête doivent être récupérées à l'aide de la méthodequeries.reports.list
avec le paramètre de requêteorderBy
de "key.reportId desc" afin de garantir que la requête répertorie en premier les rapports les plus récents. - Les champs
kind
,timezoneCode
,metadata.locale
,params.includeInviteData
etschedule.nextRunMinuteOfDay
ont été supprimés. queries.create
n'exécute plus automatiquement les requêtes après sa création et le paramètre de requêteasynchronous
a été supprimé. Appelezqueries.run
aprèsqueries.create
afin de générer des rapports pour les nouvelles requêtes.- La méthode
queries.run
a été mise à jour comme suit :- Le paramètre de requête
asynchronous
a été remplacé par le paramètre de requêtesynchronous
. Le nouveau paramètre de requête fonctionne selon la logique inverse et est considéré comme "false" s'il n'est pas spécifié. De ce fait,queries.run
génère des rapports de manière asynchrone par défaut dans la version 2 plutôt que de manière synchrone, ce qui est la valeur par défaut dans la version 1.1. - Le corps de la requête a été mis à jour pour supprimer le champ
timezoneCode
et remplacer les champsdataRange
,reportDataStartTimeMs
etreportDataEndTimeMs
par un objetDataRange
attribué au champdataRange
. - La méthode renvoie l'objet
Report
obtenu au lieu d'un corps de réponse vide.
- Le paramètre de requête
- Le champ
kind
dans le corps de la réponsequeries.list
a été supprimé.
Mettre à jour les appels au service reports
- Les champs suivants de la ressource
Report
représentés à l'origine par des objets imbriqués généraux ont été modifiés pour utiliser les types d'objets suivants: - Les champs suivants de la ressource
Report
représentés à l'origine par des objets de liste générale ont été remplacés par des listes des nouveaux types d'objets suivants: - Les champs suivants de la ressource
Report
représentés à l'origine par des chaînes ont été modifiés. Leurs champs équivalents dans la version 2 sont donc représentés par de nouveaux types d'énumération et incluent des modifications apportées aux valeurs acceptables :metadata.status.format
utilise désormais l'énumérationFormat
. Lors de la conversion vers cette énumération, la valeurEXCEL_CSV
a été supprimée etFORMAT_UNSPECIFIED
a été ajoutée.metadata.status.state
utilise désormais l'énumérationState
. Lors de la conversion vers cette énumération, les valeursQUEUED
etSTATE_UNSPECIFIED
ont été ajoutées.params.options.pathQueryOptions.channelGrouping.rules[].disjunctiveMatchStatements[].eventFilters[].dimensionFilter.match
etparams.options.pathQueryOptions.pathFilters[].eventFilters[].dimensionFilter.match
utilisent désormais l'énumérationMatch
.params.options.pathQueryOptions.pathFilters[].pathMatchPosition
utilise désormais l'énumérationPathMatchPosition
. Lors de la conversion vers cette énumération, la valeurPATH_MATCH_POSITION_UNSPECIFIED
a été ajoutée.params.type
utilise désormais l'énumérationReportType
. Lors de la conversion vers cette énumération, de nombreuses modifications ont été apportées. Elles sont listées en détail dans la section précédente concernant la mise à jour des appels de service des requêtes.
- Les champs
metadata.reportDataStartTimeMs
etmetadata.reportDataEndTimeMs
ont été remplacés par les champsreportDataStartDate
etreportDataEndDate
dans l'objetReportMetadata
. Les nouveaux champs utilisent des objetsDate
au lieu de millisecondes depuis l'epoch Unix. metadata.status.finishTimeMs
a été remplacé par le champfinishTime
dans l'objetReportStatus
. Ce nouveau champ temporel représente la date et l'heure sous la forme d'un horodatage au format RFC3339 UTC "Zulu" au lieu d'être exprimée en millisecondes depuis l'epoch Unix.- Les champs
metadata.status.failure
etparams.includeInviteData
ont été supprimés. - Le champ
kind
dans le corps de la réponsereports.list
a été supprimé.
Mettre à jour la logique de gestion des erreurs
Les messages d'erreur de l'API ont été mis à jour dans la version 2. Ces nouveaux messages d'erreur sont plus spécifiques et, dans certains cas, fournissent des informations sur les valeurs de la requête API qui entraînent le renvoi de l'erreur. Si votre logique existante de gestion des erreurs repose sur un texte de message d'erreur spécifique, généralisez la gestion des erreurs avant de migrer vers la version 2.