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.
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. Für kostenlose Buchungen werden standardmäßig der Bezahlvorgang als Gast und alternative E-Mail-Adressen unterstützt.
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:
- 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 falschen Daten
- Geben Sie diese Fehler mit Standard-HTTP-Fehlercodes an den Client zurück. Siehe die vollständige 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 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.
- Geben Sie den HTTP-Statuscode zurück, der auf
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 dieselbeCreateBookingRequest
ein zweites Mal (mit demselbenidempotency_token
) empfangen wird, muss dieselbeCreateBookingResponse
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.