Buchungsserver implementieren

Du musst einen Buchungsserver einrichten, damit „Mit Google reservieren“ Callbacks ausführen kann, um in deinem Namen Buchungen zu erstellen und zu aktualisieren.

  • Standardimplementierung Dadurch kann „Mit Google reservieren“ im Namen des Nutzers Termine, Buchungen und Reservierungen bei dir erstellen.

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

REST API-Schnittstelle implementieren

Implementieren Sie eine API-Schnittstelle auf der Grundlage von REST. Dadurch kann Google Buchungsserveranfragen über HTTP senden.

Richte zuerst einen Entwicklungs- oder Sandbox-Buchungsserver ein, der mit der Sandbox-Umgebung „Mit Google reservieren“ verbunden werden kann. Wechseln Sie erst zu einer 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 zeigen die Methoden für jede Implementierung und Links zu den .proto-Formaten.

Standardimplementierung
Standarddienstdefinition. Laden Sie die .proto-Dienstdefinitionsdatei herunter.
Methode HTTP-Anfrage
HealthCheck GET /v3/HealthCheck/
BatchAvailabilityLookup POST /v3/BatchAvailabilityLookup/
CreateBooking POST /v3/CreateBooking/
UpdateBooking POST /v3/UpdateBooking/
GetBookingStatus POST /v3/GetBookingStatus/
ListBookings POST /v3/ListBookings/

API-Ressourcen

Buchung

Die folgenden Ressourcentypen werden in der Standardimplementierung verwendet:

Ablauf: Eine Buchung erstellen

In diesem Abschnitt erfährst du, wie eine Buchung in der Standardimplementierung erstellt wird.

Abbildung 1: Workflow zum Erstellen einer Buchung aus einem Slot
Abbildung 1: Workflow zum Erstellen einer Buchung aus einem Slot

Wenn ein Nutzer eine Buchung erstellt, sendet Google dir den Vor- und Nachnamen, die Telefonnummer und die E-Mail-Adresse, die er angegeben hat. Aus deiner Sicht muss diese Buchung als Gast bezahlt werden, da „Mit Google reservieren“ das Konto des Nutzers in deinem System nicht abrufen kann. Die endgültige Buchung muss mit den Buchungen aus dem Buchungssystem deiner Händler übereinstimmen.

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. Zur Einrichtung deines Servers empfehlen wir die Verwendung eines öffentlich verfügbaren SSL/TLS-Bestätigungstools, z. B. SSL Server Test von Qualys.

Alle Anfragen, die Google an deinen Buchungsserver sendet, werden über die HTTP-Basisauthentifizierung authentifiziert. Die Basisanmeldedaten zur Authentifizierung (Nutzername und Passwort) für Ihren 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

Sehen Sie sich zuerst die folgenden Beispielgerüste eines Buchungsservers an, der für Node.js- und Java-Frameworks geschrieben wurde:

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 falschen Daten
  • Fehler im Zusammenhang mit der Geschäftslogik
    • Geben Sie den HTTP-Statuscode zurück, der auf 200 OK gesetzt ist, und geben Sie den Fehler der Geschäftslogik im Antworttext an. Die Arten von Fehlern in der Geschäftslogik, die auftreten können, unterscheiden sich je nach Art der Serverimplementierung.

Bei der Standardimplementierung werden die möglichen Fehler in der Geschäftslogik unter Buchungsfehler erfasst und in der HTTP-Antwort zurückgegeben. Beim Erstellen oder Aktualisieren einer Ressource können Fehler in der Geschäftslogik auftreten. Das betrifft zum Beispiel die Methoden CreateBooking oder UpdatingBooking. Hier einige Beispiele:

  • SLOT_UNAVAILABLE wird verwendet, wenn der angeforderte Slot nicht mehr verfügbar ist.
  • PAYMENT_ERROR_CARD_TYPE_REJECTED wird verwendet, wenn der angegebene Kreditkartentyp nicht akzeptiert wird.

Idempotenz

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

  • CreateBooking
  • UpdateBooking

Für jede Anfragenachricht außer UpdateBooking werden Idempotenz-Tokens verwendet, um die Anfrage eindeutig zu identifizieren. Damit können Sie zwischen einem wiederholten REST-Aufruf mit der Absicht, eine einzelne Anfrage zu erstellen, und zwei separaten Anfragen unterscheiden. UpdateBooking wird anhand ihrer Buchungseintrags-IDs eindeutig identifiziert, sodass in ihren Anfragen kein Idempotenz-Token enthalten ist.

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

  • Eine erfolgreiche CreateBooking-HTTP-Antwort enthält die erstellte Buchung. In einigen Fällen wird die Zahlung im Rahmen des Buchungsvorgangs verarbeitet. Wenn genau dieselbe CreateBookingRequest ein zweites Mal (mit demselben idempotency_token) empfangen wird, muss dieselbe CreateBookingResponse zurückgegeben werden. Es wird keine zweite Buchung erstellt und dem Nutzer wird gegebenenfalls nur einmal in Rechnung gestellt.

    Wenn ein CreateBooking-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.