Prácticas recomendadas

Las siguientes prácticas recomendadas se aplican a la integración de extremo a extremo de las reservas del Centro de Acciones y se pueden aprovechar para evitar problemas de usabilidad y rendimiento. Si los datos son de baja calidad, es posible que se elimine el inventario.

Feeds

  • Si un servicio no tiene una duración establecida, configura duration_sec en el feed de disponibilidad con una de las siguientes opciones:
    • Es la cantidad de segundos que se tarda en realizar el servicio de manera razonable.

    • Es la cantidad promedio de segundos requeridos para completar el servicio.

  • Haz que la entrada del campo Category en el feed del comercio sea específica. Por ejemplo, un restaurante puede enviar un tipo específico, como francés o japonés. Para obtener más detalles, consulta Tipos de lugar para ver los posibles valores de categoría.

  • Configura las Condiciones del Servicio específicas del comercio en el campo Terms del feed de comercios para que la siguiente nota aparezca debajo del botón Reservar:

    Si continúas, aceptas las Condiciones del Servicio de <merchant>.
    En este caso, "Condiciones del Servicio" es un vínculo que, cuando se hace clic en él, muestra el texto establecido en el campo de texto terms.

  • Comprime tus feeds con gzip.

Servidor de reservas

Para optimizar tu integración de la API de Maps Booking, haz lo siguiente:

  • Usa siempre las marcas de tiempo de UNIX en formato UTC.
  • Genera un ID de reserva único cuando se llame a una reserva nueva en la API de CreateBooking .

Actualizaciones en tiempo real

Para garantizar la mejor experiencia del usuario durante el proceso de reserva, haz lo siguiente:

  • En el caso de una implementación estándar, usa la API de BookingNotifications para cambiar la hora de inicio, la duración y el estado de la reserva de una cita (por ejemplo, si se cancela o no se presenta).
  • Ante cualquier cambio de tu parte en las reservas del Centro de acciones, envía siempre actualizaciones de reservas en tiempo real desde el sistema con la API de BookingNotification en tiempo real, de modo que los datos no queden inactivos en el Centro de acciones. Por ejemplo, puedes cancelar, reprogramar o actualizar una reserva desde tu sistema en el Centro de acciones.
  • Para cada actualización de reserva a partir de UpdateBookingRequest, asegúrate de que el valor UpdateBookingResponse contenga el ID de reserva y que todos los campos actualizados reflejen el valor nuevo.
  • Si se implementa Inventory RTU, haz lo siguiente:
    • Solo actualiza la disponibilidad en lotes de 100 a 1,000 ranuras por llamada a la API.
    • Usa los campos *Restrict (como startTimeRestrict) para reducir el objetivo de edición, reducir el tamaño de la carga útil y evitar volver a enviar demasiados datos sin cambios.
    • Si generas varios subprocesos, debes implementar una retirada exponencial para evitar errores de regulación. Si no implementas una retirada exponencial de forma correcta, es posible que recibas un error de cuota RESOURCE_EXHAUSTED. Puedes reintentar la retirada exponencial para controlarlas, pero si notas que tu servidor a menudo alcanza cuotas cuando ejecutas ReplaceServiceAvailability, configúralo para que reemplace por lotes para la disponibilidad. Esta solución evita errores de cuota porque reduce la cantidad de llamadas a la API que debe hacer tu entrega.
  • Establece los límites de tiempo de respuesta de las llamadas a la API en menos de un segundo. Asegúrate de que tu servidor pueda manejar cinco consultas por segundo (QPS) con una latencia inferior a un segundo al menos el 95% del tiempo.