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

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.

• Implémentation des listes d'attente pour les réservations. Vous pouvez vous en servir lorsque vous participez au programme pilote de listes d'attente pour les réservations. Cela permet au Centre d'actions de récupérer des estimations d'attente et de créer des entrées dans des listes d'attente au nom de l'utilisateur.
• 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. 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.

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 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 de service 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: l'entrée d'un utilisateur dans la 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 pour les réservations.

Lorsque l'utilisateur crée une entrée dans la liste d'attente, Google vous envoie son prénom, son nom, son numéro de téléphone et son adresse e-mail. L'adresse e-mail est identique à celle du compte Google de l'utilisateur et est traitée comme un identifiant unique. De votre côté, cette liste d'attente doit être considérée 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 dernière entrée dans la liste d'attente semble identique aux entrées de vos marchands provenant de votre système de listes d'attente.

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 disponible sans frais, 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 l'intégration des listes d'attente de réservations, les erreurs de logique métier sont capturées dans l'échec de la logique métier sur les listes d'attente 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 :

• ABOVE_MAX_PARTY_SIZE est utilisé lorsque le nombre de personnes indiqué dans la liste d'attente dépasse le nombre maximal de personnes indiqué par le marchand.
• MERCHANT_CLOSED est utilisé 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, 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:

• CreateWaitlistEntry
• DeleteWaitlistEntry

Pour chaque message de requête, à l'exception de DeleteWaitlistEntry, 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. DeleteWaitlistEntry est identifié de manière unique par leurs ID d'entrée dans la liste d'attente, respectivement, de sorte qu'aucun jeton d'idempotence n'est inclus dans leurs requêtes.

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

• Une réponse HTTP CreateWaitlistEntry réussie inclut l'ID d'entrée créé dans la liste d'attente. Si le même CreateWaitlistEntryRequest est reçu une deuxième fois (avec le même idempotency_token), le même CreateWaitlistEntryResponse doit alors être renvoyé. Aucune deuxième entrée dans la liste d'attente n'est créée, et aucune erreur n'est renvoyée.

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