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.
![Figure 2: Processus de création d'une entrée dans une liste d'attente](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/waitlists/rest_api_v3_waitlist_flow.png?authuser=19&hl=fr)
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.
- Renvoyez le code d'état HTTP défini sur
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êmeCreateWaitlistEntryRequest
est reçu une deuxième fois (avec le mêmeidempotency_token
), le mêmeCreateWaitlistEntryResponse
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.