Bonnes pratiques

Les bonnes pratiques suivantes s'appliquent à l'intégration de bout en bout de Réserver avec Google et peuvent être exploitées pour éviter les problèmes d'ergonomie et de performances. Une faible qualité des données peut entraîner le retrait de l'inventaire.

Flux

  • Si la longueur d'un service n'est pas définie, définissez duration_sec dans le flux disponibilité en utilisant 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 l'entrée du champ Category dans le flux du marchand est spécifique. Par exemple, un restaurant peut indiquer un type spécifique, comme le français ou le japonais. Pour en savoir plus, consultez Types de lieux pour connaître les valeurs de catégories potentielles.

  • Définissez les conditions d'utilisation propres au marchand dans le champ Terms du flux marchand afin que la note 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.

  • Compressez vos flux à l'aide de gzip.

Serveur de réservation

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

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

Mises à jour en temps réel

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

  • Pour 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 (annulation ou absence au rendez-vous, par exemple).
  • Lorsque vous effectuez une réservation via Réserver avec Google de votre côté, envoyez toujours en temps réel les mises à jour des réservations du système à l'aide de l'API BookingNotification, afin que les données ne soient pas obsolètes du côté de Réserver avec Google. Par exemple, vous pouvez annuler, reprogrammer ou mettre à jour une réservation à partir de votre système dans Réserver avec Google.
  • 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 Inventaire RTU est mis en œuvre
    • 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 non modifié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 effectuer un remplacement par lot pour la disponibilité. Cette solution empêche les erreurs de quota, car elle réduit le nombre d'appels d'API que vous devez effectuer.
  • Définissez des temps de réponse aux appels d'API inférieurs à une seconde. Assurez-vous que votre serveur peut gérer cinq requêtes par seconde (RPS) avec une latence inférieure à la seconde au moins 95% du temps.