Schritt 3: Wartelisten-Buchungsserver implementieren

Du musst einen Buchungsserver einrichten, damit das Actions Center Rückrufe senden kann, um Buchungen in deinem Namen zu erstellen und zu aktualisieren.

• Implementierung von Wartelisten für Reservierungen Diese wird verwendet, wenn Sie am Pilotprogramm „Wartelisten für Reservierungen“ teilnehmen. So kann das Actions Center im Namen des Nutzers geschätzte Wartezeiten abrufen und Wartelisteneinträge erstellen.
• Die Standardimplementierung: So können über das Actions Center im Namen des Nutzers Termine, Buchungen und Reservierungen bei Ihnen erstellt werden. Informationen zur Implementierung eines Buchungsservers für die End-to-End-Integration von Reservierungen findest du unter Buchungsserver implementieren.

In der Dokumentation zum Partner-Portal erfährst du, wie du die Verbindung zu deiner Sandbox und zu Produktions-Buchungsservern konfigurierst.

REST API-Schnittstelle implementieren

Implementiere eine API-Schnittstelle auf der Grundlage von REST. So kann Google Buchungsserveranfragen über HTTP senden.

Richte zuerst einen Entwicklungs- oder Sandbox-Buchungsserver ein, der mit der Actions Center-Sandbox-Umgebung verbunden werden kann. Wechsle erst dann in eine Produktionsumgebung, wenn der Sandbox-Server vollständig getestet wurde.

Methoden

Für jede Art von Buchungsserver sind unterschiedliche API-Methoden erforderlich. Optional können Sie die Dienstdefinition im .proto-Format herunterladen, um mit der API-Implementierung zu beginnen. Die folgenden Tabellen enthalten die Methoden für die einzelnen Implementierungen sowie Links zu den Dienstproto-Formaten.

Wartelistenbasierte Implementierung
Dienstleistungsdefinition – Wartelistenbasiert. Laden Sie die .proto-Dienstdefinitionsdatei 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 erfahren Sie, wie Sie eine Buchung für die Integration von Wartelisten für Reservierungen erstellen.

Wenn der Nutzer einen Wartelisteneintrag erstellt, sendet Google dir den Namen, den Nachnamen, die Telefonnummer und die E-Mail-Adresse des Nutzers. Die E-Mail-Adresse ist mit dem Google-Konto des Nutzers identisch und wird als eindeutige Kennung behandelt. Aus deiner Sicht muss diese Warteliste wie eine Option für den Bezahlvorgang als Gast behandelt werden, da „Mit Google reservieren“ das Konto des Nutzers in deinem System nicht nachschlagen kann. Achte darauf, dass der endgültige Wartelisteneintrag mit den Einträgen deiner Händler aus deinem Wartelistensystem identisch ist.

Sicherheit und Authentifizierung

Die gesamte Kommunikation mit deinem Buchungsserver erfolgt über HTTPS. Daher muss dein Server ein gültiges TLS-Zertifikat haben, das mit seinem DNS-Namen übereinstimmt. Wir empfehlen zur Unterstützung der Servereinrichtung die Verwendung eines kostenlosen SSL/TLS-Überprüfungstools wie SSL Server Test von Qualys.

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

Beispielimplementierungen für Skeletons

Sieh dir zuerst die folgenden Beispielskeletons eines Buchungsservers an, die für Node.js- und Java-Frameworks geschrieben 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 Ihr Back-End HTTP-Anfragen verarbeitet, können zwei Arten von Fehlern auftreten.

• Fehler im Zusammenhang mit der Infrastruktur oder falschen Daten
  • Geben Sie diese Fehler mit Standard-HTTP-Fehlercodes an den Client zurück. Weitere Informationen finden Sie in der vollständigen Liste der HTTP-Statuscodes.
• Fehler im Zusammenhang mit der Geschäftslogik
  • Geben Sie den HTTP-Statuscode zurück, der auf 200 OK gesetzt ist, und geben Sie im Antworttext den Fehler in der Geschäftslogik an. Die Arten von Geschäftslogikfehlern, die auftreten können, unterscheiden sich je nach Art der Serverimplementierung.

Bei der Integration von Wartelisten für Reservierungen werden Fehler in der Geschäftslogik in der Warteliste – Business Logic Failure erfasst und in der HTTP-Antwort zurückgegeben. Fehler in der Geschäftslogik können auftreten, wenn eine Ressource erstellt wird, z. B. beim Verarbeiten der Methode CreateWaitlistEntry. Dazu zählen unter anderem:

• ABOVE_MAX_PARTY_SIZE wird verwendet, wenn der angeforderte Eintrag in der Warteliste die maximale Gruppengröße des Händlers überschreitet.
• MERCHANT_CLOSED wird verwendet, wenn die Warteliste nicht geöffnet ist, weil der Händler bereits geschlossen ist.

Idempotenz

Die Kommunikation über das Netzwerk ist nicht immer zuverlässig und Google kann HTTP-Anfragen wiederholen, wenn keine Antwort empfangen wird. Aus diesem Grund müssen alle Methoden, die den Status ändern, idempotent sein:

• CreateWaitlistEntry
• DeleteWaitlistEntry

Für jede Anfragenachricht außer DeleteWaitlistEntry werden Idempotenztokens verwendet, um die Anfrage eindeutig zu identifizieren. Auf diese Weise können Sie zwischen einem REST-Aufruf, der wiederholt und mit der Absicht eine einzelne Anfrage erstellen soll, und zwei separaten Anfragen unterscheiden. DeleteWaitlistEntry wird anhand der jeweiligen Wartelisteneintrags-ID eindeutig identifiziert, sodass in den Anfragen kein Idempotenztoken enthalten ist.

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

• Eine erfolgreiche CreateWaitlistEntry-HTTP-Antwort enthält die ID des erstellten Wartelisteneintrags. Wenn dieselbe CreateWaitlistEntryRequest (mit demselben idempotency_token) ein zweites Mal empfangen wird, muss auch dieselbe CreateWaitlistEntryResponse zurückgegeben werden. Es wird kein zweiter Wartelisteneintrag erstellt und es wird 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.