Jeśli używasz interfejsu REST interfejsu Google Ads API, pracujesz z kodem JSON reprezentacja tych samych zasobów i typów, które są zdefiniowane w interfejsie Google Ads API deskryptorami.proto. Schemat kodowania JSON jest zgodny z instrukcją kanoniczny schemat kodowania opisany w Sekcja mapowania JSON protokołu buforuje Przewodnik po języku.
Ogólnie wszystkie wiadomości najwyższego poziomu wysyłane i odbierane
services to pojedyncze obiekty JSON.
Większość żądań mutacji zawiera tablicę operations
, która sama zawiera wiele
Operacje create
, update
lub delete
. Podobnie search
odpowiedzi są
Obiekty JSON zawierające tablicę results
z zestawem wyników zapytania.
Identyfikatory są przekształcane z snake_case (w buforach protokołu) na
lowerCamelCase w formacie JSON. Istotnym zastrzeżeniem jest to, że użycie
search
lub searchStream
, aby wysłać język zapytań Google Ads
zapytań. W samym języku zapytań użyto wielkości liter jak wąż, niezależnie od tego
używanego przez Ciebie interfejsu. Wyniki zapytania w architekturze REST są jednak zwracane jako
zwykłych obiektów JSON, a ich identyfikatory są zapisane małymi literami.
Na przykład zapytanie pozwalające pobrać listę aktywnych słów kluczowych na koncie korzysta z
wielkość liter w samym zapytaniu (ad_group_criterion
, a nie adGroupCriterion
):
POST /v17/customers/CUSTOMER_ID/googleAds:searchStream HTTP/1.1 Host: googleads.googleapis.com Content-Type: application/json Authorization: Bearer ACCESS_TOKEN developer-token: DEVELOPER_TOKEN { "query": "SELECT ad_group_criterion.keyword.text FROM ad_group_criterion WHERE ad_group_criterion.type = 'KEYWORD' AND ad_group_criterion.status = 'ENABLED'" }
Odpowiedź jest jednak reprezentacją obiektów JSON (opakowaną w formacie JSON)
tablica, ponieważ to żądanie używa identyfikatora searchStream
) i używa identyfikatora CamlCase
adGroupCriterion
w zamian:
[ { "results": [ { "adGroupCriterion": { "resourceName": "customers/1842689525/adGroupCriteria/55771861891~10003060", "keyword": { "text": "pay per click" } } }, ... ] } ]