Étape 4: Implémenter le serveur de réservation

Vous devez mettre en place un serveur de réservation pour permettre au Centre d'actions d'effectuer des rappels afin de créer et de mettre à jour des réservations en votre nom.

• La mise en œuvre standard. Cela permet au Centre d'actions de créer des rendez-vous et des réservations auprès de votre établissement au nom de l'utilisateur.

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

Mettre en œuvre une interface API REST

Mettez en œuvre une interface API basée sur REST. Google pourra alors envoyer des requêtes du serveur de réservation via le protocole HTTP.

Pour commencer, configurez un serveur de réservation de développement ou de bac à sable pouvant être connecté à l'environnement de bac à sable Actions Center. Ne passez à un environnement de production qu'une fois que le serveur de bac à sable a été entièrement testé.

Méthodes

Vous devez mettre en œuvre un ensemble différent de méthodes API pour chaque type de serveur de réservation. Pour vous aider à vous lancer dans la mise en œuvre de l'API, vous pouvez télécharger la définition du service au format proto. Les tableaux suivants présentent les méthodes associées à chaque implémentation et incluent des liens vers les formats de définition du service au format proto.

Mise en œuvre standard
Définition du service (mise en œuvre standard) Téléchargez le fichier de définition du service au format 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 :

• Slot: créneau d'inventaire
• Réservation: rendez-vous pris dans 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.

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 le Centre d'actions ne peut pas accéder au compte de l'utilisateur dans votre système. Assurez-vous que la réservation finale se présente de manière identique aux réservations effectuées auprès de vos marchands au sein de votre système de réservation.

Sécurité et authentification

Toutes les communications avec votre serveur de réservation se font via le protocole HTTPS. Votre serveur doit donc disposer d'un certificat TLS valide associé à son nom DNS. Pour vous aider à configurer votre serveur, nous vous recommandons d'utiliser un outil de validation SSL/TLS disponible publiquement, tel que le SSL Server Test de Qualys.

Toutes les requêtes envoyées par Google à votre serveur de réservation seront authentifiées à l'aide de l'authentification HTTP standard. Les identifiants d'authentification standards (nom d'utilisateur et mot de passe) de votre serveur de réservation peuvent être saisis sur la page "Booking Server Configuration" (Configuration du serveur de réservation) du portail des partenaires. Les mots de passe doivent être modifiés tous les six mois.

Remarque:Vous devez définir le nom d'utilisateur et le mot de passe pour le bac à sable et la production séparément à l'aide du commutateur d'environnement.

Exemples de mise en œuvre de squelettes

Pour commencer, examinez ci-dessous des exemples de squelettes d'un serveur de réservation, codés 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
  • Renvoyer le code d'état HTTP défini sur 200 OK et spécifier 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 diffèrent selon les types de mises en œuvre du serveur.

Dans la mise en œuvre standard, les erreurs de logique métier possibles sont capturées dans la spécification BookingFailure 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 deux exemples:

• L'erreur SLOT_UNAVAILABLE est utilisée si le créneau demandé n'est plus disponible.
• L'erreur PAYMENT_ERROR_CARD_TYPE_REJECTED est utilisée 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 est susceptible de retenter l'envoi de requêtes HTTP si aucune réponse n'est reçue. Par conséquent, toutes les méthodes qui modifient l'état doivent être idempotentes:

• CreateBooking
• UpdateBooking

Pour que la requête soit identifiée de manière unique, des jetons d'idempotence sont inclus dans chaque message de requête, à l'exception de UpdateBooking. Cela vous permet de faire la distinction entre une nouvelle tentative d'appel REST (dont l'intention est de créer une seule requête) et l'envoi de deux requêtes distinctes. UpdateBooking est identifié de manière unique par ses ID d'entrée de réservation. Aucun jeton d'idempotence n'est donc 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 positive inclut la réservation créée. Dans certains cas, le paiement est traité pendant le processus de réservation. Si exactement la même requête CreateBookingRequest est reçue une deuxième fois (avec le même jeton idempotency_token), c'est la même réponse CreateBookingResponse qui doit alors être renvoyée. Une deuxième réservation n'est pas 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 retenter une réponse.

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