Étape 3: Implémenter le serveur de réservation de listes d'attente

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.

• Mise en œuvre des listes d'attente pour les réservations. Vous pouvez utiliser cette méthode si vous participez au programme pilote de listes d'attente pour les réservations. Cela permet à Actions Center de récupérer des estimations d'attente et de créer des entrées dans une liste d'attente au nom de l'utilisateur.
• 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. Pour implémenter un serveur de réservation pour l'intégration de bout en bout des réservations, consultez Mettre en œuvre le serveur de réservation.

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 basée sur des listes d'attente
Définition du service (mise en œuvre basée sur des listes d'attente). Téléchargez le fichier de définition du service au format proto.

Méthode	Requête HTTP
HealthCheck	GET /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

Ressources de l'API

Liste d'attente

Les ressources suivantes sont utilisées dans la mise en œuvre basée sur des listes d'attente :

• WaitEstimate: estimation du temps d'attente pour un nombre de personnes et un marchand spécifiques.
• WaitlistEntry: entrée d'un utilisateur dans une liste d'attente.

Flux : créer une entrée dans une liste d'attente

Cette section explique comment créer une réservation pour l'intégration des listes d'attente de réservations.

Lorsqu'un utilisateur crée une entrée dans une liste d'attente, Google vous envoie son nom, son prénom, son numéro de téléphone et son adresse e-mail. Celle-ci est identique à celle de son compte Google. Elle est traitée comme un identifiant unique. De votre côté, vous devez traiter cette entrée dans la liste d'attente comme un paiement sans connexion, car Réserver avec Google ne peut pas accéder au compte de l'utilisateur dans votre système. Assurez-vous que l'entrée finale dans la liste d'attente se présente de manière identique aux entrées enregistré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 sans frais, 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.

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.

Pour l'intégration des listes d'attente de réservations, les erreurs de logique métier sont capturées dans Waitlist Business Logic Failure et renvoyées dans la réponse HTTP. Des erreurs de logique métier peuvent se produire lors de la création d'une ressource (par exemple, lorsque vous gérez la méthode CreateWaitlistEntry). Entre autres exemples, nous n'acceptons pas les contenus suivants :

• L'erreur ABOVE_MAX_PARTY_SIZE est utilisée lorsque l'entrée demandée dans la liste d'attente dépasse le nombre maximal de personnes spécifié par le marchand.
• L'erreur MERCHANT_CLOSED est utilisée lorsque la liste d'attente n'est pas ouverte, car le marchand est déjà fermé.

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:

• CreateWaitlistEntry
• DeleteWaitlistEntry

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 DeleteWaitlistEntry. 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. DeleteWaitlistEntry est identifié de manière unique par leurs ID d'entrée dans la liste d'attente. Elles n'incluent donc aucun jeton d'idempotence.

Voici quelques exemples de la manière dont les serveurs de réservation gèrent l'idempotence :

• Une réponse HTTP CreateWaitlistEntry positive inclut l'ID de l'entrée créée dans la liste d'attente. Si la même requête CreateWaitlistEntryRequest est reçue une deuxième fois (avec le même jeton idempotency_token), c'est la même réponse CreateWaitlistEntryResponse qui doit alors être renvoyée. Une deuxième entrée n'est pas créée dans la liste d'attente, et aucune erreur n'est renvoyée.

  Notez que si une tentative de requête CreateWaitlistEntry é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.