Krok 3. Wdróż serwer rezerwacji z list oczekujących

Musisz skonfigurować serwer rezerwacji, aby umożliwić Centrum akcji wykonywanie połączeń zwrotnych w celu tworzenia i aktualizowania rezerwacji w Twoim imieniu.

• Wdrożenie list oczekujących rezerwacji. Dane te są używane, gdy uczestniczysz w programie pilotażowym listy oczekujących rezerwacji. Dzięki temu Centrum działań będzie mogło pobierać szacunki czasu oczekiwania i tworzyć wpisy do listy oczekujących w imieniu użytkownika.
• Implementacja standardowa. Pozwoli to Centrum działań tworzyć spotkania, rezerwacje i rezerwacje z Tobą w imieniu użytkownika. Aby wdrożyć serwer rezerwacji na potrzeby kompleksowej integracji rezerwacji, przeczytaj artykuł o wdrażaniu serwera rezerwacji.

Informacje o tym, jak skonfigurować połączenie z serwerem rezerwacji w trybie piaskownicy i serwerów rezerwacji w środowisku produkcyjnym, znajdziesz w dokumentacji portalu dla partnerów.

Wdrażanie interfejsu API typu REST

Wdróż interfejs API oparty na REST. Dzięki temu Google może wysyłać żądania do serwera rezerwacji przez HTTP.

Na początek skonfiguruj serwer rezerwacji w trybie programistycznym lub w trybie piaskownicy, który można połączyć ze środowiskiem piaskownicy Actions Center. Przejdź do środowiska produkcyjnego dopiero po pełnym przetestowaniu serwera piaskownicy.

Metody

W przypadku każdego typu serwera rezerwacji wymagany jest po Twojej stronie inny zestaw metod interfejsu API. Opcjonalnie możesz pobrać definicję usługi w formacie proto, aby rozpocząć implementację interfejsu API. Tabele poniżej przedstawiają metody każdej implementacji i zawierają linki do formatów protokołów usługi.

Implementacja listy oczekujących
Definicja usługi listy oczekujących. Pobierz plik definicji usługi proto.

Metoda	Żądanie HTTP
HealthCheck	POBIERZ /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGet WaitForecasts/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

Zasoby interfejsu API

Lista oczekujących

Do wdrożenia rezerwacji na podstawie listy oczekujących służą te zasoby:

• WaitEstimate szacowany czas oczekiwania dla konkretnej wielkości grupy i sprzedawcy.
• WaitlistEntry (Lista oczekujących): wpis użytkownika na liście oczekujących.

Proces: tworzenie pozycji na liście oczekujących

Z tej sekcji dowiesz się, jak utworzyć rezerwację na potrzeby integracji list oczekujących rezerwacji.

Gdy użytkownik utworzy pozycję na liście oczekujących, Google wyśle Ci jego imię, nazwisko, numer telefonu i adres e-mail. Adres e-mail jest taki sam jak konto Google użytkownika i jest traktowany jako unikalny identyfikator. Z Twojego punktu widzenia ta lista oczekujących musi być traktowana jako gość, ponieważ usługa Zarezerwuj z Google nie może wyszukać konta użytkownika w Twoim systemie. Sprawdź, czy ostateczna pozycja na liście oczekujących wygląda tak samo jak wpisy sprzedawców, które pochodzą z Twojego systemu listy oczekujących.

Zabezpieczenia i uwierzytelnianie

Cała komunikacja z serwerem rezerwacji odbywa się przez HTTPS, dlatego serwer musi mieć prawidłowy certyfikat TLS zgodny z jego nazwą DNS. Aby ułatwić sobie konfigurowanie serwera, zalecamy użycie bezpłatnego narzędzia do weryfikacji protokołu SSL/TLS, takiego jak Test serwera SSL firmy Qualys.

Wszystkie żądania, które Google będzie wysyłać do Twojego serwera rezerwacji, będą uwierzytelniane za pomocą podstawowego uwierzytelniania HTTP. Podstawowe dane uwierzytelniające (nazwę użytkownika i hasło) serwera rezerwacji można wpisać na stronie konfiguracji serwera rezerwacji w portalu dla partnerów. Hasła należy zmieniać co 6 miesięcy.

Przykładowe wdrożenia szkieletu

Zacznij od obejrzenia tych przykładowych szkieletów serwera rezerwacji napisanego dla platform Node.js i Java:

• Szkielet Node.js js-maps-booking-rest-server-v3-skeleton
• Szkielet Javy java-maps-booking-rest-server-v3-skeleton

Te serwery mają skrócone 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
  • Zwróć te błędy klientowi ze standardowymi kodami błędów HTTP. Zobacz pełną listę kodów stanu HTTP.
• Błędy związane z logiką biznesową
  • Zwróć kod stanu HTTP ustawiony na 200 OK i wskaż błąd logiki biznesowej w treści odpowiedzi. Typy błędów logiki biznesowej, które możesz napotkać, są różne w zależności od typu implementacji serwera.

W przypadku integracji list oczekujących z rezerwacjami błędy logiki biznesowej są rejestrowane w sekcji Błąd logiki biznesowej listy oczekujących i zwracane w odpowiedzi HTTP. Podczas tworzenia zasobu, np. podczas obsługi metody CreateWaitlistEntry, mogą wystąpić błędy logiki biznesowej. Przykłady (lista nie jest pełna):

• ABOVE_MAX_PARTY_SIZE jest używane, gdy wymagana pozycja na liście oczekujących przekracza maksymalną liczbę miejsc określoną przez sprzedawcę.
• Wartość MERCHANT_CLOSED jest używana, gdy lista oczekujących nie jest otwarta, ponieważ sprzedawca jest już zamknięty.

Idempotentność

Komunikacja przez sieć nie zawsze jest niezawodna i Google może ponawiać żądania HTTP, jeśli nie otrzyma odpowiedzi. Z tego powodu wszystkie metody, które mutują stan, muszą być idempotentne:

• CreateWaitlistEntry
• DeleteWaitlistEntry

W przypadku każdej wiadomości żądania oprócz DeleteWaitlistEntry dołączane są tokeny idempotentności, które pozwalają jednoznacznie zidentyfikować żądanie. Dzięki temu możesz odróżnić ponownie użyte wywołanie REST z zamiarem utworzenia pojedynczego żądania i 2 osobne żądania. Obiekt DeleteWaitlistEntry jest jednoznacznie identyfikowany przez identyfikatory pozycji na liście oczekujących, więc w żądaniach nie jest uwzględniony token idempotentności.

Oto kilka przykładów tego, jak serwery rezerwacji obsługują idempotentność:

• Pomyślna odpowiedź HTTP CreateWaitlistEntry zawiera identyfikator wpisu utworzonej na liście oczekujących. Jeśli ten sam element CreateWaitlistEntryRequest otrzyma drugi raz (z tą samą wartością idempotency_token), musi zostać zwrócony taki sam element CreateWaitlistEntryResponse. Nie zostanie utworzony drugi wpis na liście oczekujących i żaden błąd nie zostanie zwrócony.

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

Wymagania dotyczące idempotentności mają zastosowanie do wszystkich metod, które zmieniają stan.