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
200OK, 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 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_UNAVAILABLEest utilisé si le créneau demandé n'est plus disponible.PAYMENT_ERROR_CARD_TYPE_REJECTEDest 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:
CreateBookingUpdateBooking
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
CreateBookingré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êmeCreateBookingRequestest reçu une deuxième fois (avec le mêmeidempotency_token), le mêmeCreateBookingResponsedoit ê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.