Die Ad Manager API hat sowohl benannte Hauptversionen als auch abwärtskompatible In-Place-Releases für die aktuelle Hauptversion.
Dienste, Methoden und Felder können innerhalb einer Hauptversion (z. B. Version 1) jederzeit als eingestellt gekennzeichnet werden. Sie werden jedoch bis zur Einstellung dieser Hauptversion unterstützt.
Hauptversionen
Eine Hauptversion wird als Release mit nicht abwärtskompatiblen API-Änderungen definiert. Diese Releases werden benannt und haben unterschiedliche API-Endpunkte. Vorherige Hauptversionen werden für einen Migrationszeitraum unterstützt.
Für die Ad Manager API gibt es keinen regelmäßigen Releaserhythmus für die Hauptversion Versionen. Neue Hauptversionen werden nur bei Bedarf veröffentlicht.
Direkte Releases
Abwärtskompatible Änderungen, einschließlich neuer Funktionen und Fehlerkorrekturen die der aktuellen Haupt-API-Version entsprechen. Clients müssen unbekannte Felder in API-Antworten verarbeiten.
Abwärtskompatibilität
Die Abwärtskompatibilität wird für Änderungen innerhalb einer Hauptversion beibehalten. Kompatibilität ist definiert als:
Quellkompatibilität: Code, der für eine vorherige Version geschrieben wurde, kann in einer neueren Version kompiliert und mit einer neueren Version der Clientbibliothek ausgeführt werden.
Wire-Kompatibilität: Code, der aus einem früheren Release geschrieben wurde mit einem neueren Server korrekt kommuniziert. Mit anderen Worten, es sind nicht nur Eingaben und Ausgaben kompatibel, aber die Serialisierung und Deserialisierung weiter übereinstimmen.
Semantische Kompatibilität: Code, der für eine vorherige Version geschrieben wurde, funktioniert weiterhin wie erwartet.
In den folgenden Tabellen werden die Arten von API-Änderungen aufgeführt und angegeben, ob sie abwärtskompatibel sind.
Dienste
Art der Änderung | Abwärtskompatibel |
---|---|
Neuen Dienst hinzufügen | Ja |
Dienst entfernen | Nein |
Methoden
Art der Änderung | Abwärtskompatibel |
---|---|
Neue Methode hinzufügen | Ja |
Methode entfernen | Nein |
Anfrage- oder Antworttyp einer Methode ändern | Nein |
Objekte
Art der Änderung | Abwärtskompatibel |
---|---|
Pflichtfeld hinzufügen | Nein |
Optionales Feld hinzufügen | Ja |
Feld in eine untergeordnete Nachricht oder aus einer untergeordneten Nachricht verschieben | Nein |
Ein Feld von „erforderlich“ in „optional“ ändern | Ja |
Ein Feld von „optional“ in „erforderlich“ ändern | Nein |
Unveränderliche Einschränkung entfernen | Ja |
Unveränderliche Einschränkung hinzufügen | Nein |
Aufzählungen
Art der Änderung | Abwärtskompatibel |
---|---|
Enum-Wert hinzufügen | Ja |
Enum-Wert entfernen | Nein |
Verhalten eingestellter Felder
Ersatzfelder
Bei Feldern, für die es einen Ersatz gibt, werden, sofern möglich, beide Felder ausgefüllt.
Bei der Aktualisierung kann jedes Feld festgelegt werden. Wenn Sie beide Felder in eine Aktualisierungsanfrage aufnehmen, führt dies zu einem INVALID_ARGUMENT
-Fehler.
Betrachten Sie das folgende Schema:
{
// The cost of this Foo in micros.
// Deprecated: Use `cost` instead.
"costMicros": number,
// The cost of this Foo.
"cost": {
object (Money)
}
}
In einer Leseantwort werden beide Felder mit äquivalenten Werten ausgefüllt:
{
"costMicros": 1250000,
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 250000000
}
}
Bei Aktualisierungsanfragen kann entweder der eine oder der andere Wert festgelegt werden. Wenn Sie beide Felder angeben, führt das zu einem INVALID_ARGUMENT
-Fehler:
costMicros
// Update payload
{
"costMicros": 1500000
}
// Response payload
{
"costMicros": 1500000,
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 500000000
}
}
Kosten
// Update payload
{
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 500000000
}
}
// Response payload
{
"costMicros": 1500000,
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 500000000
}
}
Beides
// Update payload
{
"costMicros": 1250000,
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 500000000
}
}
// Response payload
{
"error": {
"code": 400,
"message": "Request contains an invalid argument.",
"status": "INVALID_ARGUMENT",
"details": [
{
"@type": "type.googleapis.com/google.rpc.BadRequest",
"fieldViolations": [
{
"field": "costMicros",
"description": "Cannot update both costMicros and cost."
}
]
}
]
}
}
Eingestellte Funktionen
Wenn eine Produktfunktion eingestellt wird, werden die entsprechenden Felder wie folgt gekennzeichnet: veraltet und gibt möglicherweise einen semantisch geeigneten Standardwert zurück. Aktualisierungen ignoriert werden kann.
{
// The salesperson split amount in micros.
// Deprecated: The Sales Management feature has been deprecated. This field
// will always be `0`.
"salespersonSplitMicros": number,
}