Serwer partnera

Aby zintegrować informacje o cenach i dostępności, partnerzy muszą wdrożyć interfejs Partner API. Ten interfejs jest oparty na REST i umożliwia Google przesyłanie połączeń na żywo przez HTTP. Szczegółowe informacje o poszczególnych metodach interfejsu API znajdziesz w sekcji Dokumentacja, a informacje o kwestiach przekrojowych – w dalszej części tego artykułu.

Format żądania i odpowiedzi

Początkowo obsługiwane będą tylko formaty JSON. Jeśli potrzebujesz dodatkowych formatów żądań lub odpowiedzi, skontaktuj się z zespołem ds. transportu w branży turystycznej pod adresem transport-help@google.com, aby omówić swój przypadek użycia.

Żądania będą wysyłane przy użyciu metody HTTP POST, a komunikat żądania będzie znajdować się w treści żądania POST.

Aby zapewnić przejrzystość struktury, dokumentacja interfejsu API jest udostępniana w postaci definicji wiadomości Protocol Buffer, a tłumaczenie definicji wiadomości Protocol Buffer na obiekt JSON jest zdefiniowane przez kanoniczne mapowanie JSON z użyciem opcji do emitowania pól z wartościami domyślnymi i używania nazw pól proto zamiast nazw w formacie lowerCamelCase.

Uwierzytelnianie

Google obsługuje uwierzytelnianie HTTP Digest i uwierzytelnianie za pomocą certyfikatu klienta. Wszystkie wywołania HTTP interfejsu Partner API korzystają z uwierzytelniania HTTP Digest (z nazwą użytkownika i hasłem) lub uwierzytelniania za pomocą certyfikatu klienta. Partner powinien przekazać Google nazwę użytkownika i hasło (patrz sekcja Konfiguracja partnera) lub certyfikat klienta SSL.

Kody stanu i obsługa błędów

Ogólnie w odpowiedziach HTTP mogą być zwracane te kody stanu:

Kod HTTP Opis HTTP Uwagi
2xx OK Nie jest to błąd. Zwracany w przypadku powodzenia. Treść odpowiedzi powinna zawierać wynik (np. TripOptionsResult), a nie odpowiedź z błędem.
400 Nieprawidłowe żądanie Otrzymane żądanie było nieprawidłowe. Odpowiedzi o błędach specyficzne dla metody powinny być używane do zwracania dodatkowych szczegółów błędu w treści odpowiedzi. Błąd HTTP 400 powinien być używany tylko wtedy, gdy Google popełniło błąd techniczny (np. w żądaniu wystąpiło pole o nieprawidłowej nazwie).
403 Zabroniono Odmowa dostępu lub brak dostępu (dzwoniący jest znany i odrzucony). Tej odpowiedzi nie należy używać w przypadku odrzucenia spowodowanego wyczerpaniem zasobów (w takich przypadkach użyj odpowiedzi Too Many Requests). Nie można używać kodu Forbidden, jeśli nie można zidentyfikować wywołującego (w przypadku tych błędów użyj kodu Unauthorized).
404 Nie znaleziono Nie znaleziono żądanego zasobu. Odpowiedzi o błędach specyficzne dla metody powinny być używane do zwracania dodatkowych szczegółów błędu w treści odpowiedzi.
429 Za wiele próśb Jeden z zasobów został wyczerpany, być może limit na użytkownika.
500 Wewnętrzny błąd serwera Błędy wewnętrzne. Oznacza to, że pewne niezmienniki oczekiwane przez system bazowy zostały uszkodzone. Ten kod błędu jest zarezerwowany dla poważnych błędów i wskazuje błąd w implementacji serwera API partnera.
503 Usługa jest niedostępna Usługa jest niedostępna. Jest to najczęściej stan przejściowy, który można rozwiązać, ponawiając próbę z wycofywaniem.
504 Przekroczony czas bramy Termin upłynął przed wykonaniem operacji. W przypadku operacji, które zmieniają stan systemu, ten błąd może zostać zwrócony nawet wówczas, gdy operacja zakończyła się pomyślnie. Na przykład pomyślna odpowiedź serwera mogła być tak opóźniona, że termin upłynął.

Pamiętaj, że w przypadku wszystkich błędów dotyczących warunków wstępnych, nieprawidłowych argumentów lub braku danych:

  • należy używać odpowiedzi lub komunikatów o błędach specyficznych dla metody zdefiniowanych w interfejsach API.
  • należy użyć prawidłowego kodu HTTP, zgodnie z kodami określonymi dla danej metody (np.TripOptionsErrorType).

Dzięki temu można podać bardziej szczegółowe informacje o tych typach błędów. Te informacje mogą być wykorzystywane do:

  • Sprawdzanie, czy można ponowić próbę wykonania działania w przypadku błędu
    • Nie można ponowić próby SEGMENT_KEY_NOT_FOUND.
  • Poprawianie nieaktualnych informacji
    • Unavailable.Reason.CANCELED oznacza, że podróż powinna zostać usunięta (pamiętaj, że jest to część odpowiedzi informującej o powodzeniu).
    • Unavailable.Reason.TEMPORARILY_UNAVAILABLE oraz kody błędów SEGMENT_KEY_NOT_FOUND, SUBOPTIMAL_ITINERARY, BOOKING_WINDOW_NOT_SUPPORTED i TICKETING_PROHIBITED usuwają wszelkie ceny, które wcześniej otrzymaliśmy z pamięci podręcznej.
  • Udzielaj użytkownikom odpowiednich wskazówek

Obecna lista błędów specyficznych dla metod podana w TripOptionsError jest punktem wyjścia. Jeśli potrzebujesz dodatkowych typów błędów, skontaktuj się z zespołem Google Travel Transport.

QPS (zapytania na sekundę)

Liczba zapytań na sekundę wysyłanych przez Google może się różnić w zależności od zasobów reklamowych partnera i liczby użytkowników, którzy wyświetlają dane w pamięci podręcznej lub klikają witryny partnerów w celu dokonania rezerwacji.

Czas oczekiwania

Żądania przekraczają limit czasu po 10 sekundach. W przypadku integracji partnerów w wersji beta nie będą obowiązywać żadne dodatkowe wytyczne dotyczące opóźnień. Dalsze limity SLO dotyczące opóźnień zostaną określone w naszych wskazówkach dotyczących jakości danych partnera.

Waluty, podatki i opłaty

Wszystkie ceny przesyłane do Google muszą zawierać wszystkie podatki i opłaty oraz być podane w obsługiwanej walucie.

Waluta

Walutę ceny określa się za pomocą pola currency_code, które musi być prawidłowym kodem waluty zgodnym ze standardem ISO 4217.

Przykład:10,25 PLN

{
  "price": {
    "currency_code": "USD",
    "units": 10,
    "nanos": 250000000
  }
}

Podatki i opłaty

Podana cena musi być ostateczną, całkowitą ceną, jaką zapłaci użytkownik. Musi ona zawierać wszystkie podatki (np. VAT) i dodatkowe opłaty (np. opłaty za rezerwację lub kartę płatniczą). Opcjonalny podział opłaty można dodać za pomocą powtarzalnego pola line_items. Google wyświetli użytkownikowi łączną cenę z opcjonalnym podziałem ceny.