Vous devez mettre en place un serveur de réservation pour permettre à Réserver avec Google d'effectuer des rappels pour créer et mettre à jour les réservations en votre nom.
- L'implémentation standard. Cela permet à Réserver avec Google de créer des rendez-vous et des réservations au nom de l'utilisateur.
Consultez la documentation du portail des partenaires pour savoir comment configurer la connexion à vos serveurs de bac à sable et de réservation en production.
Mettre en œuvre une interface API REST
Implémenter une interface API basée sur REST. Cela permet à Google d'envoyer des requêtes de serveur de réservation via HTTP.
Pour commencer, configurez un serveur de développement ou de réservation dans le bac à sable pouvant être connecté à l'environnement de bac à sable Réserver avec Google. Ne passez à un environnement de production qu'une fois le serveur de bac à sable entièrement testé.
Méthodes
Pour chaque type de serveur de réservation, un ensemble différent de méthodes API est requis de votre côté. Vous pouvez éventuellement télécharger la définition du service au format proto pour commencer à implémenter l'API. Les tableaux suivants présentent les méthodes pour chaque mise en œuvre et incluent des liens vers les formats du protocole de service.
Mise en œuvre standard |
---|
Définition de service standard : téléchargez le fichier de définition de service proto. |
Méthode | Requête HTTP |
---|---|
HealthCheck | GET /v3/HealthCheck/ |
BatchAvailabilityLookup | POST /v3/BatchAvailabilityLookup/ |
CreateBooking | POST /v3/CreateBooking/ |
UpdateBooking | POST /v3/UpdateBooking/ |
GetBookingStatus | POST /v3/GetBookingStatus/ |
ListBookings | POST /v3/ListBookings/ |
Ressources de l'API
Réservation
Les types de ressources suivants sont utilisés dans la mise en œuvre standard :
- Emplacement: emplacement d'inventaire.
- Réservation: rendez-vous pour un créneau d'inventaire.
Flux : créer une réservation
Cette section vous explique comment créer une réservation dans la mise en œuvre standard.
Lorsqu'un utilisateur crée une réservation, Google vous envoie son nom, son prénom, son numéro de téléphone et son adresse e-mail. De votre côté, vous devez traiter cette réservation comme un paiement sans connexion, car Réserver avec Google ne peut pas rechercher le compte de l'utilisateur dans votre système. Assurez-vous que la réservation finale est identique à celle fournie par le marchand via votre système de réservation. Le paiement sans connexion et les adresses e-mail secondaires sont pris en charge par défaut pour les réservations non payantes.
Sécurité et authentification
Toutes les communications avec votre serveur de réservation se font via HTTPS. Il est donc essentiel que votre serveur dispose d'un certificat TLS valide correspondant à son nom DNS. Pour vous aider à configurer votre serveur, nous vous recommandons d'utiliser un outil de validation SSL/TLS public, tel que le test de serveur SSL de Qualys.
Toutes les requêtes que Google enverra à votre serveur de réservation seront authentifiées à l'aide de l'authentification de base HTTP. Vous pouvez saisir les identifiants d'authentification de base (nom d'utilisateur et mot de passe) de votre serveur de réservation sur la page de configuration du serveur de réservation du portail des partenaires. Les mots de passe doivent être renouvelés tous les six mois.
Exemples de mise en œuvre de squelettes
Pour commencer, consultez les exemples suivants de squelettes d'un serveur de réservation, écrits pour les frameworks Node.js et Java:
- Squelette Node.js js-maps-booking-rest-server-v3-skeleton
- Squelette Java java-maps-booking-rest-server-v3-skeleton
Ces serveurs servent de bouchon pour les méthodes REST.
Conditions requises
Erreurs HTTP et de logique métier
Lorsque votre backend traite des requêtes HTTP, deux types d'erreurs peuvent se produire.
- Erreurs liées à l'infrastructure ou données incorrectes
- Renvoyez ces erreurs au client à l'aide des codes d'erreur HTTP standards. Consultez la liste complète des codes d'état HTTP.
- Erreurs liées à la logique métier
- Renvoyez le code d'état HTTP sur
200
OK, puis spécifiez l'échec de la logique métier dans le corps de la réponse. Les types d'erreurs de logique métier que vous pouvez rencontrer varient selon les types de mises en œuvre du serveur.
- Renvoyez le code d'état HTTP sur
Pour l'implémentation standard, les erreurs de logique métier possibles sont capturées dans la section Échec de la réservation et renvoyées dans la réponse HTTP. Des erreurs de logique métier peuvent se produire lors de la création ou de la mise à jour d'une ressource. Par exemple, lorsque vous gérez les méthodes CreateBooking
ou UpdatingBooking
. Voici quelques exemples (liste non exhaustive) :
SLOT_UNAVAILABLE
est utilisé si l'emplacement demandé n'est plus disponible.PAYMENT_ERROR_CARD_TYPE_REJECTED
est utilisé si le type de carte de crédit fourni n'est pas accepté.
Idempotence
La communication sur le réseau n'est pas toujours fiable. Google peut relancer les requêtes HTTP si aucune réponse n'est reçue. Pour cette raison, toutes les méthodes qui modifient l'état doivent être idempotentes:
CreateBooking
UpdateBooking
Pour chaque message de requête, à l'exception de UpdateBooking
, des jetons d'idempotence sont inclus pour identifier la requête de manière unique. Cela vous permet de faire la distinction entre un appel REST renouvelé, avec l'intention de créer une seule requête, et deux requêtes distinctes.
UpdateBooking
est identifié de manière unique par son ID d'entrée de réservation. Par conséquent, aucun jeton d'idempotence n'est inclus dans ses requêtes.
Voici quelques exemples de la manière dont les serveurs de réservation gèrent l'idempotence :
Une réponse HTTP
CreateBooking
réussie inclut la réservation créée. Dans certains cas, le paiement est traité dans le cadre du processus de réservation. Si le mêmeCreateBookingRequest
est reçu une deuxième fois (avec le mêmeidempotency_token
), le mêmeCreateBookingResponse
doit être renvoyé. Aucune seconde réservation n'est créée et l'utilisateur n'est facturé qu'une seule fois, le cas échéant.Notez que si une tentative de requête
CreateBooking
échoue et que la même requête est renvoyée, votre backend doit réessayer.
La condition d'idempotence s'applique à toutes les méthodes qui modifient l'état.