Krok 3. Wprowadź serwer rezerwacji list oczekujących

Musisz uruchomić serwer rezerwacji, aby umożliwić Centrum działań wykonywanie wywołań zwrotnych w celu tworzenia i aktualizowania rezerwacji w Twoim imieniu.

• Implementacja list oczekujących na rezerwacje. Jest on używany, gdy bierzesz udział w programie pilotażowym list rezerwowych. Umożliwia to Centrum działań pobieranie szacunków czasu oczekiwania i tworzenie wpisów na liście oczekujących w imieniu użytkownika.
• Standardowa implementacja. Dzięki temu Centrum działań może tworzyć spotkania, rezerwacje i rezerwacje w Twoim imieniu w imieniu użytkownika. Aby wdrożyć serwer rezerwacji w ramach kompleksowej integracji z rezerwacjami, zapoznaj się z artykułem Wdrażanie serwera rezerwacji.

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.

Wdrożenie listy oczekujących
Definicja usługi listy oczekujących. Pobierz plik definicji usługi proto.

Metoda	Żądanie HTTP
HealthCheck	GET /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

Zasoby interfejsu API

Lista oczekujących

Do wdrażania rezerwacji na podstawie listy oczekujących służą te zasoby:

• WaitEstimate (szacowany czas oczekiwania): szacunkowy czas oczekiwania dla konkretnego rozmiaru grupy i sprzedawcy.
• WaitlistEntry: wpis użytkownika na liście oczekujących.

Proces: tworzenie pozycji na liście oczekujących

Z tej sekcji dowiesz się, jak utworzyć rezerwację w ramach integracji z listą oczekujących.

Gdy użytkownik utworzy wpis na liście oczekujących, Google wyśle Ci jego imię i nazwisko, nazwisko, numer telefonu i adres e-mail. Adres e-mail jest taki sam jak adres konta Google użytkownika i traktowany jako unikalny identyfikator. Z Twojego punktu widzenia ta lista oczekujących powinna być traktowana jako płatność gościa, ponieważ Rezerwacja z Google nie może sprawdzić konta użytkownika w Twoim systemie. Upewnij się, że ostatni wpis na liście oczekujących jest identyczny z wpisami Twoich sprzedawców pochodzącymi z systemu listy oczekujących.

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 bezpłatnego 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 integracji z listami oczekujących rezerwacji błędy logiki biznesowej są rejestrowane w błędzie logiki biznesowej listy oczekujących i zwracane w odpowiedzi HTTP. Błędy logiki biznesowej mogą wystąpić podczas tworzenia zasobu, na przykład podczas obsługi metody CreateWaitlistEntry. Przykłady (lista nie jest pełna):

• ABOVE_MAX_PARTY_SIZE jest używany, gdy żądany wpis na liście oczekujących przekracza maksymalną liczbę osób w grupie klienta.
• MERCHANT_CLOSED jest używany, gdy lista oczekujących jest zamknięta, ponieważ sprzedawca już zamknął sklep.

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:

• CreateWaitlistEntry
• DeleteWaitlistEntry

W przypadku każdej wiadomości z żądaniem oprócz DeleteWaitlistEntry 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ń. DeleteWaitlistEntry jest jednoznacznie zidentyfikowany za pomocą identyfikatorów wpisów na liście oczekujących, dlatego w żądaniach nie jest dołączany token idempotentności.

Oto kilka przykładów tego, jak serwery rezerwacji obsługują idempotencję:

• Odpowiedź HTTP CreateWaitlistEntry po pomyślnym zakończeniu operacji zawiera identyfikator utworzonego wpisu na liście oczekujących. Jeśli ten sam CreateWaitlistEntryRequest zostanie otrzymany po raz drugi (z tym samym idempotency_token), należy zwrócić ten sam CreateWaitlistEntryResponse. Nie tworzy się drugi wpis na liście oczekujących i nie jest zwracany żaden błąd.

  Pamiętaj, że jeśli próba CreateWaitlistEntry zakończy się niepowodzeniem i to samo żądanie zostanie ponownie wysłane, backend powinien w tym przypadku spróbować ponownie.

Wymóg idempotentności dotyczy wszystkich metod, które zmieniają stan.