Schritt 3: Buchungsserver für Wartelisten implementieren

Sie müssen einen Buchungsserver einrichten, damit das Actions Center Rückrufe ausführen kann, um Buchungen in Ihrem Namen zu erstellen und zu aktualisieren.

• Die Implementierung von Wartelisten für Reservierungen: Sie wird verwendet, wenn du am Pilotprogramm für Reservierungswartelisten teilnimmst. So können im Actions Center im Namen des Nutzers geschätzte Wartezeiten abgerufen und Wartelisteneinträge erstellt werden.
• Die Standardimplementierung: So kann das Actions Center im Namen des Nutzers Termine, Buchungen und Reservierungen bei dir erstellen. Informationen zum Implementieren eines Buchungsservers für die End-to-End-Integration von Reservierungen finden Sie unter Buchungsserver implementieren.

In der Dokumentation zum Partner-Portal kannst du nachlesen, wie du die Verbindung zu deinen Sandbox- und Produktionsbuchungsservern konfigurierst.

REST API-Schnittstelle implementieren

Implementiere eine REST, damit Google Buchungsserveranfragen über HTTP senden kann.

Dazu richtest du zuerst einen Entwicklungs- oder Sandbox-Buchungsserver ein, der mit der Sandbox-Umgebung des Actions Centers verbunden werden kann. Du solltest erst zu einer Produktionsumgebung wechseln, nachdem der Sandbox-Server vollständig getestet wurde.

Methoden

Für jede Art von Buchungsserver sind unterschiedliche API-Methoden erforderlich. Optional kannst du die Dienstleistungsdefinition im .proto-Format herunterladen, um mit der API-Implementierung zu beginnen. In den folgenden Tabellen findest du die Methoden für jede Implementierung und Links zu den .proto-Formaten.

Wartelistenbasierte Implementierung
Dienstleistungsdefinition – Wartelistenbasiert. Lade die Dienstleistungsdefinition im .proto-Format herunter.

Methode	HTTP-Anfrage
HealthCheck	GET /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

API-Ressourcen

Warteliste

Die folgenden Ressourcen werden für die Implementierung von wartelistenbasierten Buchungen verwendet:

• WaitEstimate: Eine Schätzung der Wartezeit für eine bestimmte Gruppengröße und einen bestimmten Händler.
• WaitlistEntry: Der Eintrag eines Nutzers in der Warteliste.

Ablauf: Einen Wartelisteneintrag erstellen

In diesem Abschnitt erfährst du, wie du eine Buchung für die Integration von Reservierungswartelisten erstellst.

Wenn ein Nutzer einen Wartelisteneintrag erstellt, sendet Google dir den Namen, den Nachnamen, die Telefonnummer und die E-Mail-Adresse, die er angegeben hat. Die E-Mail-Adresse stimmt mit dem Google-Konto des Nutzers überein und wird als eindeutige Kennung behandelt. Die Funktion „Mit Google reservieren“ kann das Konto des Nutzers in deinem System nicht abrufen. Daher musst du diesen Eintrag wie einen „Eintrag als Gast“ behandeln. Der endgültige Wartelisteneintrag muss mit den Einträgen deiner Händler aus deinem Wartelistensystem übereinstimmen.

Sicherheit und Authentifizierung

Die gesamte Kommunikation mit deinem Buchungsserver erfolgt über HTTPS. Daher muss der Server ein gültiges TLS-Zertifikat haben, das mit seinem DNS-Namen übereinstimmt. Wir empfehlen dir, bei der Einrichtung deines Servers ein kostenloses SSL/TLS-Verifizierungstool zu verwenden, z. B. SSL Server Test von Qualys.

Alle Anfragen, die Google an deinen Buchungsserver sendet, werden über die HTTP-Basisauthentifizierung authentifiziert. Die Anmeldedaten für die Basisauthentifizierung (Nutzername und Passwort) für deinen Buchungsserver können auf seiner Konfigurationsseite im Partner-Portal eingegeben werden. Passwörter müssen alle sechs Monate rotiert werden.

Beispielimplementierungen für Skeletons

Sieh dir zuerst die folgenden Beispiel-Skeletons eines Buchungsservers an, die für Node.js- und Java-Frameworks erstellt wurden:

• Node.js-Skeleton: js-maps-booking-rest-server-v3-skeleton
• Java-Skeleton: java-maps-booking-rest-server-v3-skeleton

Diese Server haben REST-Methoden, die weiter ausgebaut werden können (Stubs).

Voraussetzungen

HTTP-Fehler und Fehler in der Geschäftslogik

Wenn dein Back-End HTTP-Anfragen verarbeitet, sind zwei Arten von Fehlern möglich:

• Fehler im Zusammenhang mit der Infrastruktur oder falsche Daten
  • Diese Fehler werden mit den Standard-HTTP-Fehlercodes an den Client zurückgegeben. Weitere Informationen findest du in der vollständigen Liste der HTTP-Statuscodes.
• Fehler im Zusammenhang mit der Geschäftslogik
  • Gib den HTTP-Statuscode 200 OK zurück und gib den Fehler in der Geschäftslogik im Antworttext an. Die möglichen Fehler in der Geschäftslogik unterscheiden sich je nach Art der Serverimplementierung.

Bei der Integration von Reservierungswartelisten werden Fehler in der Geschäftslogik in WaitlistBusinessLogicFailure (Wartelistenbasierte Fehler in der Geschäftslogik) erfasst und in der HTTP-Antwort zurückgegeben. Fehler in der Geschäftslogik können auftreten, wenn eine Ressource erstellt wird, etwa beim Verarbeiten der Methode CreateWaitlistEntry. Dazu zählen unter anderem:

• ABOVE_MAX_PARTY_SIZE wird verwendet, wenn der angeforderte Wartelisteneintrag die maximale Gruppengröße des Händlers überschreitet.
• MERCHANT_CLOSED wird verwendet, wenn kein Wartelisteneintrag erstellt werden kann, weil der Händler bereits geschlossen hat.

Idempotenz

Die Kommunikation über das Netzwerk ist nicht immer zuverlässig. Daher sendet Google HTTP-Anfragen eventuell noch einmal, wenn keine Antwort zurückgegeben wird. Aus diesem Grund müssen alle Methoden, die den Status ändern, idempotent sein:

• CreateWaitlistEntry
• DeleteWaitlistEntry

Für jede Anfragenachricht außer DeleteWaitlistEntry werden Idempotenz-Token verwendet, um die Anfrage eindeutig zu identifizieren. Dadurch kannst du zwischen einem REST-Aufruf, der noch einmal gesendet wurde und über den eine einzelne Anfrage erstellt werden soll, und zwei separaten Anfragen unterscheiden. DeleteWaitlistEntry werden eindeutig über ihre IDs für den Wartelisteneintrag identifiziert. Daher ist in diesen Anfragen kein Idempotenz-Token enthalten.

Nachfolgend findest du einige Beispiele dafür, wie Server Idempotenz verarbeiten:

• Eine erfolgreiche HTTP-Antwort auf CreateWaitlistEntry enthält die ID des erstellten Wartelisteneintrags. Wenn dieselbe CreateWaitlistEntryRequest-Anfrage ein zweites Mal (mit demselben idempotency_token) eingeht, muss auch dieselbe CreateWaitlistEntryResponse-Antwort zurückgegeben werden. Es wird kein zweiter Wartelisteneintrag erstellt und kein Fehler zurückgegeben.

  Wenn ein CreateWaitlistEntry-Versuch fehlschlägt und dieselbe Anfrage noch einmal gesendet wird, sollte das Back-End einen neuen Versuch starten.

Die Idempotenz-Vorgabe gilt für alle Methoden, die den Status ändern.