Zanim zaczniesz
- Poproś opiekuna klienta o skonfigurowanie odpowiednich uprawnień dla kont, do których aplikacja będzie miała dostęp.
- Jeśli nie masz doświadczenia z pojęciami związanymi z Authorized Buyers, odwiedź Centrum pomocy Authorized Buyers i poeksperymentuj z interfejsem. Jeśli Twoja aplikacja ma działać z określaniem stawek w czasie rzeczywistym, przeczytaj dokumentację protokołu RTB.
- Otwórz Konsolę interfejsów API, by skonfigurować nowy projekt. Zaloguj się na swoje konto Google dewelopera lub je utwórz. Zobaczysz prośbę o utworzenie projektu i zaakceptowanie kilku Warunków korzystania z usługi.
Konta nadrzędne i podrzędne
Jeśli pracujesz w strukturze konta zawierającej konta nadrzędne i podrzędne, możesz pracować wydajniej, jeśli zrozumiesz, jak one wchodzą ze sobą w interakcję. Oto krótkie podsumowanie:
Konta podrzędne
Użytkownik z danymi logowania, które przyznają dostęp do konta podrzędnego, może tylko wyświetlać i modyfikować zasoby powiązane z jego kontem. Na kontach podrzędnych nie można wyświetlać ani modyfikować zasobów należących do innych kont podrzędnych lub nadrzędnych.
Konta nadrzędne
Użytkownik z danymi logowania, które przyznają dostęp do konta nadrzędnego, może wyświetlać i modyfikować zasoby konta nadrzędnego oraz wszystkie powiązane z nim konta podrzędne. W przypadku wyświetlania listy wszystkich zasobów danego zasobu ten użytkownik otrzyma odpowiedź zawierającą dane dotyczące jego konta i wszystkich jego kont podrzędnych. Pamiętaj, że w przypadku innych typów żądań kierowanych na zasoby dla stanowisk podrzędnych konto nadrzędne musi określać parametr ścieżki accountId
konta podrzędnego, a nie własnego konta accountId
.
Model danych interfejsu API REST
Zasób to pojedynczy element danych z unikalnym identyfikatorem. Zasób „Accounts” (Konta) reprezentuje wpis na koncie Authorized Buyers i jest główną klasą danych interfejsu Ad Exchange Buyer API. Metody interfejsu API działają na poszczególnych zasobach kont i zbiorach zasobów kont.
Zasób „Konta” obejmuje: identyfikator konta, informacje używane podczas dopasowywania plików cookie, lokalizacje licytującego, adres URL, do którego wysyłane są pytania o stawkę, oraz żądanie określenia maksymalnej liczby zapytań na sekundę, która ma być wysyłana przez Ad Exchange.
Oprócz zasobów i zbierania zasobów Konta interfejs Ad Exchange Buyer API definiuje te struktury danych:
- Lokalizacja licytującego
Lokalizacje licytujących to struktury zwracane w Zasobach kont, które zawierają adres URL, na który Ad Exchange ma wysyłać pytania o stawkę, oraz maksymalną liczbę zapytań na sekundę, jaką ma wysłać Ad Exchange. Oto przykład lokalizacji licytującego zapisanej w formacie JSON:
"bidderLocation": [ { "url": "http://bid.url.com/bidder", "maximumQps": 1500 } ],
- Elementy
Elementy zawierają listę kont. Oto przykład elementów zapisanych w formacie JSON:
{ "kind": "adexchangebuyer#accountsList", "items": [ accounts Resource ] }
Obsługiwane operacje
W interfejsie Ad Exchange Buyer API możesz wywoływać 3 różne metody związane z kolekcjami i zasobami zgodnie z opisem w tabeli poniżej. Wszystkie operacje wymagają autoryzacji.
Operacja | Opis | Mapowania HTTP REST |
---|---|---|
list | Wyświetla listę wszystkich kont, do których ma dostęp aktualnie uwierzytelnione konto użytkownika. | GET o identyfikatorze URI kolekcji. |
pobierz | Pobiera określony zasób Konta. | GET w identyfikatorze URI zasobu. |
aktualizacja | Aktualizuje określony zasób Konta. | PUT w identyfikatorze URI zasobu, gdzie należy przekazywać dane dla zaktualizowanego zasobu. |
Styl połączeń
REST to styl architektury oprogramowania zapewniający wygodne i spójne podejście do żądania i modyfikowania danych.
Termin REST to skrót od „Representational State Transfer”. W kontekście interfejsów API Google odnosi się do korzystania z czasowników HTTP do pobierania i modyfikowania reprezentacji danych przechowywanych przez Google.
W systemie REST zasoby są przechowywane w magazynie danych. Klient wysyła żądanie, aby serwer przystąpił do realizacji konkretnego działania (na przykład utworzenia, pobrania, zaktualizowania lub usunięcia zasobu), serwer wykonuje działanie i wysyła odpowiedź, często w formie reprezentacji określonego zasobu.
W interfejsach API Google typu REST klient określa działanie przy użyciu czasownika HTTP, takiego jak POST
, GET
, PUT
czy DELETE
. Zasób określa go za pomocą unikalnego identyfikatora URI, który ma postać:
https://www.googleapis.com/apiName/apiVersion/resourcePath?parameters
Wszystkie zasoby interfejsu API mają unikalne identyfikatory URI dostępne przez HTTP, dlatego REST umożliwia buforowanie danych i jest zoptymalizowany pod kątem współpracy z rozproszoną infrastrukturą sieci.
Definicje metod można znaleźć w dokumentacji standardów HTTP 1.1. Obejmują one specyfikacje GET
, POST
, PUT
i DELETE
.
REST w interfejsie Ad Exchange Buyer API
Obsługiwane operacje mapują się bezpośrednio na czasowniki HTTP REST zgodnie z opisem w sekcji Operacje interfejsu API.
Szczegółowy format identyfikatorów URI interfejsów API to:
https://www.googleapis.com/adexchangebuyer/v1.4/resourceID?parameters
gdzie resourceID
to identyfikator zasobu Konta, a parameters
to parametry stosowane do zapytania. Więcej informacji znajdziesz w standardowych parametrach zapytania i w dokumentacji.
Format rozszerzeń ścieżki resourceID
pozwala Ci zidentyfikować zasób, na którym obecnie pracujesz. Na przykład:
https://www.googleapis.com/adexchangebuyer/v1.4/accounts
https://www.googleapis.com/adexchangebuyer/v1.4/accounts/id
Podsumowanie pełnych identyfikatorów URI używanych w przypadku każdej obsługiwanej operacji w interfejsie API znajdziesz w dokumentacji referencyjnej.
Oto przykład, jak to działa w interfejsie Ad Exchange Buyer API.
Pobierz listę kont uwierzytelnionego użytkownika:
GET https://www.googleapis.com/adexchangebuyer/v1.4/accounts
Format danych
JSON
JSON (JavaScript Object Notation) to popularny, niezależny od języka format danych, który przedstawia proste struktury danych w formie tekstowej. Więcej informacji znajdziesz na stronie json.org.