Krok 4. Wprowadź serwer rezerwacji

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.

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.

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.

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 sam CreateBookingRequest zostanie otrzymany po raz drugi (z tym samym idempotency_token), należy zwrócić ten sam CreateBookingResponse. 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.