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.
![Rysunek 2. Proces tworzenia pozycji na liście oczekujących](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/waitlists/rest_api_v3_waitlist_flow.png?authuser=4&hl=pl)
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.
- Zwróć kod stanu HTTP ustawiony na
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 elementCreateWaitlistEntryRequest
otrzyma drugi raz (z tą samą wartościąidempotency_token
), musi zostać zwrócony taki sam elementCreateWaitlistEntryResponse
. 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.