Musisz uruchomić serwer rezerwacji, aby umożliwić Centrum działań wykonywanie wywołań zwrotnych w celu tworzenia i aktualizowania rezerwacji w Twoim imieniu.
- Standardowa implementacja. Dzięki temu Centrum działań może tworzyć spotkania, rezerwacje i rezerwacje w Twoim imieniu w imieniu użytkownika.
- Implementacja listy oczekujących. Ta opcja jest używana, gdy bierze się udział w programie pilotażowym listy oczekujących. Umożliwia to Centrum działań pobieranie szacunków czasu oczekiwania i tworzenie wpisów na liście oczekujących w imieniu użytkownika. Aby wdrożyć serwer rezerwacji dla listy oczekujących, zapoznaj się z artykułem Wdrażanie serwera rezerwacji dla listy oczekujących.
Aby dowiedzieć się, jak skonfigurować połączenie z serwerem rezerwacji w piaskownicy i na produkcyjnym serwerze rezerwacji, zapoznaj się z dokumentacją Portalu Partnera.
Wdrażanie interfejsu API typu REST
Wdrożyć interfejs API oparty na protokole REST. Pozwoli to Google na wysyłanie żądań do serwera rezerwacji przez HTTP.
Na początek skonfiguruj serwer rezerwacji w wersji testowej lub w środowisku testowym, który można połączyć z środowiskiem testowym w Centrum działań. Przejdź do środowiska produkcyjnego dopiero wtedy, gdy serwer piaskownicy zostanie w pełni przetestowany.
Metody
W przypadku każdego typu serwera rezerwacji wymagany jest inny zestaw metod interfejsu API. Opcjonalnie możesz pobrać definicję usługi w formacie proto, aby rozpocząć implementację interfejsu API. Poniższe tabele zawierają metody dla poszczególnych implementacji oraz linki do formatów usługi.
Implementacja standardowa |
---|
Standardowa definicja usługi Pobierz plik definicji usługi proto. |
Metoda | Żądanie HTTP |
---|---|
HealthCheck | GET /v3/HealthCheck/ |
BatchAvailabilityLookup | POST /v3/BatchAvailabilityLookup/ |
CreateBooking | POST /v3/CreateBooking/ |
UpdateBooking | POST /v3/UpdateBooking/ |
GetBookingStatus | POST /v3/GetBookingStatus/ |
ListBookings | POST /v3/ListBookings/ |
Zasoby interfejsu API
Rezerwacja
W standardowej implementacji używane są te typy zasobów:
- Slot: slot asortymentu.
- Rezerwacja: spotkanie dotyczące slotu w zasobach.
Proces: tworzenie rezerwacji
Z tej sekcji dowiesz się, jak utworzyć rezerwację w przypadku implementacji standardowej.
Gdy użytkownik utworzy rezerwację, Google wyśle Ci jego imię, nazwisko, numer telefonu i adres e-mail. Z Twojego punktu widzenia rezerwacja powinna zostać potraktowana jako płatność bez logowania, ponieważ Centrum działań nie może sprawdzić konta użytkownika w Twoim systemie. Upewnij się, że ostateczna rezerwacja jest identyczna z rezerwacjami Twoich sprzedawców pochodzącymi z Twojego systemu rezerwacji. Płatności bezpłatnych rezerwacji są domyślnie obsługiwane przez proces zapłaty gościa i alternatywne adresy e-mail.
Zabezpieczenia i uwierzytelnianie
Cała komunikacja z serwerem rezerwacji odbywa się przez HTTPS, dlatego ważne jest, aby Twój serwer miał prawidłowy certyfikat TLS zgodny z nazwą DNS. Aby ułatwić konfigurowanie serwera, zalecamy użycie publicznie dostępnego narzędzia do weryfikacji SSL/TLS, takiego jak Qualys SSL Server Test.
Wszystkie żądania wysyłane przez Google do Twojego serwera rezerwacji będą uwierzytelniane za pomocą podstawowego uwierzytelniania HTTP. Podstawowe dane uwierzytelniające (nazwa użytkownika i hasło) do serwera rezerwacji można wpisać na stronie Konfiguracja serwera rezerwacji w Portalu partnera. Hasła należy zmieniać co 6 miesięcy.
Przykładowe implementacje szkieletu
Na początek zapoznaj się z tymi przykładowymi szkieletami serwera rezerwacji napisanymi w ramach platform Node.js i Java:
- Szkielet Node.js js-maps-booking-rest-server-v3-skeleton
- Szkielet Java java-maps-booking-rest-server-v3-skeleton
Te serwery mają zablokowane metody REST.
Wymagania
Błędy HTTP i błędy logiki biznesowej
Gdy backend obsługuje żądania HTTP, mogą wystąpić 2 rodzaje błędów.
- Błędy związane z infrastrukturą lub nieprawidłowymi danymi
- Zwracaj te błędy klientowi za pomocą standardowych kodów błędów HTTP. Zapoznaj się z pełną listą kodów stanu HTTP.
- Błędy związane z logiką biznesową
- Zwracać kod stanu HTTP ustawiony na
200
OK i wskazywać błąd logiki biznesowej w treści odpowiedzi. Typy błędów logiki biznesowej, na które możesz się natknąć, różnią się w zależności od typu implementacji serwera.
- Zwracać kod stanu HTTP ustawiony na
W przypadku implementacji standardowej możliwe błędy logiki biznesowej są rejestrowane w błędach rezerwacji i zwracane w odpowiedzi HTTP. Podczas tworzenia lub aktualizowania zasobu mogą wystąpić błędy logiki biznesowej. Na przykład, gdy obsługujesz metody CreateBooking
lub UpdatingBooking
. Oto kilka przykładów:
- Wartość
SLOT_UNAVAILABLE
jest używana, jeśli żądany przedział czasu jest niedostępny. - Jeśli podany typ karty kredytowej nie jest akceptowany, używana jest wartość
PAYMENT_ERROR_CARD_TYPE_REJECTED
.
Idempotentność
Komunikacja przez sieć nie zawsze jest niezawodna, dlatego Google może powtórzyć żądania HTTP, jeśli nie otrzyma odpowiedzi. Z tego powodu wszystkie metody, które zmieniają stan, muszą być idempotentne:
CreateBooking
UpdateBooking
W przypadku każdej wiadomości z żądaniem oprócz UpdateBooking
uwzględniane są tokeny idempotentności, które umożliwiają jednoznaczną identyfikację żądania. Dzięki temu możesz odróżnić powtórne wywołanie metody REST, które ma na celu utworzenie pojedynczego żądania, od 2 oddzielnych żądań.
UpdateBooking
jest jednoznacznie zidentyfikowany za pomocą identyfikatorów wpisów rezerwacji, więc w żądaniach nie jest dołączany token idempotentności.
Oto kilka przykładów tego, jak serwery rezerwacji obsługują idempotencję:
W przypadku powodzenia odpowiedź HTTP
CreateBooking
zawiera utworzoną rezerwację. W niektórych przypadkach płatności są przetwarzane w ramach procesu rezerwacji. Jeśli dokładnie ten samCreateBookingRequest
zostanie otrzymany po raz drugi (z tym samymidempotency_token
), należy zwrócić ten samCreateBookingResponse
. Nie tworzona jest druga rezerwacja, a użytkownikowi naliczona zostaje opłata tylko raz (jeśli to konieczne).Pamiętaj, że jeśli próba
CreateBooking
się nie powiedzie i ta sama prośba zostanie ponownie wysłana, backend powinien ją powtórzyć.
Wymóg idempotentności dotyczy wszystkich metod, które zmieniają stan.