Mettre en œuvre le serveur de réservation

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 :

Flux : créer une réservation

Cette section vous explique comment créer une réservation dans la mise en œuvre standard.

Figure 1: Processus de création d'une réservation à partir d'un emplacement
Figure 1: Processus de création d'une réservation à partir d'un créneau

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:

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
  • 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.

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ême CreateBookingRequest est reçu une deuxième fois (avec le même idempotency_token), le même CreateBookingResponse 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.