Étape 4: Mettez en œuvre le serveur de réservation

Vous devez mettre en place un serveur de réservation pour autoriser Actions Center à effectuer des rappels afin de créer et de mettre à jour des réservations en votre nom.

• L'implémentation standard. Cela permet au Centre d'actions de créer des rendez-vous et des réservations avec vous au nom de l'utilisateur.

Consultez la documentation du portail des partenaires pour savoir comment configurer la connexion à votre bac à sable et à vos serveurs de réservation de production.

Mettre en œuvre une interface API REST

Mettre en œuvre une interface API basée sur REST. Cela permet à Google d'envoyer des requêtes au serveur de réservation via HTTP.

Pour commencer, configurez un serveur de réservation de développement ou de bac à sable qui peut être connecté à l'environnement de bac à sable d'Actions Center. 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, vous devez utiliser un ensemble différent de méthodes d'API. Vous pouvez éventuellement télécharger la définition du service au format proto pour commencer à mettre en œuvre l'API. Les tableaux suivants présentent les méthodes pour chaque mise en œuvre et incluent des liens vers les formats proto du 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 prénom, son nom, son numéro de téléphone et son adresse e-mail. De votre côté, cette réservation doit être traitée comme un paiement sans connexion, car Actions Center ne peut pas rechercher le compte de l'utilisateur dans votre système. Assurez-vous que la réservation finale semble identique aux réservations effectuées par vos marchands dans votre système de réservation.

Sécurité et authentification

Toutes les communications avec votre serveur de réservation s'effectuent via HTTPS. Il est donc essentiel que votre serveur dispose d'un certificat TLS valide correspondant à son nom DNS. Pour faciliter la configuration de votre serveur, nous vous recommandons d'utiliser un outil de validation SSL/TLS accessible au public, tel que le test de serveur SSL de Qualys.

Toutes les requêtes envoyées par Google à 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 "Configuration du serveur de réservation" du portail des partenaires. Les mots de passe doivent être alternés tous les six mois.

Exemples de mise en œuvre de squelettes

Pour commencer, consultez les exemples de squelettes suivants d'un serveur de réservation écrit 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 à des 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 défini 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 de serveur.

Pour la mise en œuvre standard, les erreurs de logique métier possibles sont capturées dans Booking Failure 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. Il peut s'agir, entre autres, des produits suivants:

• SLOT_UNAVAILABLE est utilisé si le créneau 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, et Google peut relancer les requêtes HTTP si aucune réponse n'est reçue. C'est pourquoi 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 une nouvelle tentative d'appel REST, dans le but 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, de sorte qu'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 exactement 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 deuxième 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 CreateBooking échoue et que la même requête est renvoyée, votre backend doit retenter l'opération.

La condition d'idempotence s'applique à toutes les méthodes qui modifient l'état.