Bonnes pratiques

Les bonnes pratiques suivantes s'appliquent à l'intégration de bout en bout des rendez-vous dans le Centre d'actions. Elles permettent d'éviter les problèmes d'usabilité et de performances. Une faible qualité des données peut entraîner le retrait de l'inventaire.

Flux

  • Si aucune durée n'est définie pour un service, définissez duration_sec dans le flux de disponibilité sur l'une des valeurs suivantes :
    • Nombre de secondes nécessaires pour exécuter le service de manière raisonnable.

    • Nombre moyen de secondes nécessaires pour effectuer le service.

  • Assurez-vous que la saisie du champ Category dans le flux marchand est spécifique. Par exemple, un restaurant peut indiquer un type spécifique, tel que français ou japonais. Pour en savoir plus sur les valeurs de catégorie potentielles, consultez Types de lieux.

  • Définissez les conditions d'utilisation propres au marchand dans le champ Terms du flux Merchant Center afin que la remarque suivante s'affiche sous le bouton Réserver:

    En continuant, vous acceptez les conditions d'utilisation de <merchant>.
    Dans ce cas, "Conditions d'utilisation" est un lien qui, lorsque l'utilisateur clique dessus, affiche le texte défini dans le champ de texte terms.

  • Compresser vos flux à l'aide de gzip

Serveur de réservation

Pour optimiser votre intégration de l'API Maps Booking, procédez comme suit:

  • Utilisez toujours les horodatages UNIX au format UTC.
  • Générer un ID de réservation unique lorsqu'une nouvelle réservation est appelée dans l'API CreateBooking .

Mises à jour en temps réel

Pour garantir la meilleure expérience utilisateur possible lors du processus de réservation, procédez comme suit:

  • Dans le cadre d'une implémentation standard, utilisez l'API BookingNotifications pour modifier l'heure de début, la durée et l'état de la réservation d'un rendez-vous, par exemple en cas d'annulation ou de non-présentation.
  • En cas de modification de votre part concernant la réservation dans Actions Center, envoyez systématiquement des mises à jour de réservation en temps réel depuis le système avec l'API BookingNotification afin que les données ne deviennent pas obsolètes dans Actions Center. Par exemple, vous pouvez annuler, reprogrammer ou mettre à jour une réservation depuis votre système dans le Centre d'actions.
  • Pour chaque mise à jour de réservation de UpdateBookingRequest, assurez-vous que la valeur UpdateBookingResponse contient l'ID de réservation et que tous les champs mis à jour doivent refléter la nouvelle valeur.
  • Si des mises à jour en temps réel d'inventaire sont implémentées
    • Ne mettez à jour la disponibilité que par lots de 100 à 1 000 emplacements par appel d'API.
    • Utilisez des champs *Restrict (tels que startTimeRestrict) pour affiner la cible de modification, réduire la taille de la charge utile et éviter de renvoyer trop de données inchangées.
    • Si vous désactivez plusieurs threads, mettez en œuvre un intervalle exponentiel entre les tentatives pour éviter les erreurs de limitation. Si vous n'implémentez pas correctement un intervalle exponentiel entre les tentatives, vous pouvez obtenir une erreur de quota RESOURCE_EXHAUSTED. Vous pouvez relancer l'intervalle exponentiel entre les tentatives pour les gérer, mais si vous constatez que votre serveur atteint souvent des quotas lorsque vous exécutez ReplaceServiceAvailability, configurez-le pour qu'il effectue un remplacement groupé pour la disponibilité. Cette solution permet d'éviter les erreurs de quota, car elle réduit le nombre d'appels d'API que votre diffusion doit effectuer.
  • Définissez des limites de temps de réponse aux appels d'API à moins d'une seconde. Assurez-vous que votre serveur peut traiter cinq requêtes par seconde (RPS) avec une latence inférieure à une seconde au moins 95% du temps.