Soumissionnaires - Changements cassants

Notre API de bus d’impression et notre protocole d’enchère sont en constante évolution. La grande majorité des modifications sont des ajouts transparents de nouvelles fonctionnalités, mais nous introduisons parfois des « changements cassants » qui peuvent vous obliger à ajuster votre intégration.

Cette page explique quels changements sont qualifiés de « changements cassants » dans notre API de bus d’impression et notre protocole d’enchère. Il vous donne également des exemples de modifications qui ne sont pas de qualité comme des changements cassants.

Remarque

Xandr se réserve le droit de corriger les bogues, d’ajuster les fonctionnalités pour se conformer à nos politiques de service et obligations légales, et de modifier les fonctionnalités et les produits dans les versions alpha et bêta sans préavis.

Impression bus API

Dans le contexte de notre API Impression Bus, les types de modifications suivants sont qualifiés de changements cassants :

• Suppression d’un champ.
• Passage d’un champ de non obligatoire à obligatoire.
• Ajout de nouvelles règles de validation.
• Modification du type de données d’un champ (par exemple, tableau d’ID convertis en tableau d’objets).
• Modification de la limitation des requêtes.
• Réduction du nombre d’objets retournés par les réponses.

Lorsque nous introduisons un changement cassant dans notre API impression bus, nous prenons en charge deux versions de l’API en production, l’une avec et l’autre sans changement cassant, pendant 60 jours. Nous allons annoncer ces modifications et comment atteindre correctement chaque version pendant la période des changements cassants (voir Réception des notifications de changement cassant).

Protocole d’enchère

Dans le contexte de notre protocole d’appel d’offres (demandes et réponses), les types de modifications suivants sont considérés comme des changements cassants :

• Suppression d’un champ.
• Passage d’un champ de non obligatoire à obligatoire.
• Modification du type de données d’un champ (par exemple, tableau d’ID convertis en tableau d’objets).

Nous annoncerons les changements cassants apportés à notre protocole d’enchères au moins 45 jours avant que les modifications ne prennent effet (voir Réception des notifications de changement cassant).

Exemples de modifications non cassants

Les types de modifications suivants ne sont pas de qualité comme des changements cassants. Notez que cette liste n’est pas exhaustive ; il ne s’agit que de quelques exemples de modifications non cassants.

• Ajout d’un nouveau champ non obligatoire (API ou protocole d’enchère).
• Ajout d’un nouveau service (API).
• Ajout de métriques/dimensions aux rapports (API).
• Ajout d’un nouveau type de rapport (API).
• Dépréciation d’un champ sans le supprimer (API ou protocole d’enchère).
• Réduction ou augmentation du nombre de rapports simultanés autorisés (API).
• Modification de l’ordre des champs dans un objet, des objets d’un tableau, etc. (API ou protocole d’enchère).

Réception de notifications de changement cassant

• Si vous disposez d’un compte d’utilisateur Xandr, vous recevrez automatiquement des communications de changement cassant.
• Si vous n’avez pas votre propre compte d’utilisateur Xandr, vous pouvez vous inscrire pour recevoir des communications sur le site Microsoft Advertising Xandr.