Paso 3: Implementa el servidor de reservas de listas de espera

Debes crear un servidor de reservas a fin de permitir que el Centro de acciones realice devoluciones de llamada para crear y actualizar reservas en tu nombre.

• La implementación de listas de espera de Reservations. Se usa cuando participas en el programa piloto de listas de espera de Reservations. Esto permite que el Centro de acciones recupere estimaciones de espera y cree entradas de lista de espera en nombre del usuario.
• Implementación estándar. Esto permite que el Centro de acciones cree citas y reservas contigo en nombre del usuario. Si quieres implementar un servidor de reservas para la integración de extremo a extremo de Reservations, consulta Implementa el servidor de reservas.

Consulta la documentación del Portal para socios a fin de obtener información sobre cómo configurar la conexión a tus servidores de reservas de producción y zona de pruebas.

Implementa una interfaz de API de REST

Implementa una interfaz de API basada en REST. Esto permite que Google envíe solicitudes del servidor de reservas a través de HTTP.

Para comenzar, configura un servidor de reservas de zona de pruebas o desarrollo que se pueda conectar al entorno de la zona de pruebas del Centro de acciones. Solo migra a un entorno de producción una vez que el servidor de zona de pruebas esté completamente probado.

Métodos

Para cada tipo de servidor de reservas, se requiere un conjunto diferente de métodos de API. De manera opcional, puedes descargar la definición del servicio en formato proto para comenzar con la implementación de la API. En las siguientes tablas, se muestran los métodos para cada implementación y se incluyen vínculos a los formatos proto del servicio.

Implementación de lista de espera
Definición de Servicio de lista de espera. Descarga el archivo proto de definición del servicio.

Método	Solicitud HTTP
HealthCheck	GET /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

Recursos de la API

Lista de espera

Los siguientes recursos se usan para implementar reservas basadas en listas de espera:

• WaitEstimate: Una estimación del tiempo de espera para un tamaño de grupo y un comercio específicos.
• WaitlistEntry: Es la entrada de un usuario en la lista de espera.

Flujo: Cómo crear una entrada de lista de espera

En esta sección, se explica cómo crear una reserva para la integración de listas de espera de Reservations.

Cuando el usuario crea una entrada de lista de espera, Google te envía el nombre, el apellido, el número de teléfono y el correo electrónico del usuario. El correo electrónico es el mismo que el de la Cuenta de Google del usuario y se trata como un identificador único. Desde tu punto de vista, esta lista de espera debe tratarse como una confirmación de la compra como invitado, ya que Reserva con Google no puede buscar la cuenta del usuario en tu sistema. Asegúrate de que la entrada final de la lista de espera sea idéntica a las entradas de tus comercios que provienen de tu sistema de listas de espera.

Seguridad y autenticación

Toda la comunicación con tu servidor de reservas se realiza a través de HTTPS, por lo que es fundamental que tu servidor tenga un certificado TLS válido que coincida con su nombre de DNS. Para ayudarte a configurar el servidor, te recomendamos usar una herramienta de verificación de SSL/TLS gratuita, como la SSL Server Test de Qualys.

Todas las solicitudes que realice Google a tu servidor de reservas se autenticarán con la autenticación básica HTTP. Las credenciales de autenticación básicas (nombre de usuario y contraseña) de tu servidor de reservas se pueden ingresar en la página Configuración del servidor de reservas del Portal para socios. Las contraseñas se deben rotar cada seis meses.

Ejemplos de esquemas de implementación

Para comenzar, consulta los siguientes ejemplos de esqueletos de un servidor de reservas escrito para los frameworks de Node.js y Java:

• Esquema de Node.js js-maps-booking-rest-server-v3-skeleton
• Esquema de Java java-maps-booking-rest-server-v3-skeleton

Estos servidores simulan nuestros métodos REST.

Requisitos

Errores de HTTP y de lógica empresarial

Cuando tu backend controla las solicitudes HTTP, pueden ocurrir dos tipos de errores.

• Errores relacionados con la infraestructura o datos incorrectos
  • Muestra estos errores al cliente con códigos de error HTTP estándar. Consulta la lista completa de códigos de estado HTTP.
• Errores relacionados con la lógica empresarial
  • Muestra el código de estado HTTP establecido en 200 OK y especifica la falla de lógica empresarial en el cuerpo de la respuesta. Los tipos de errores de lógica empresarial que puedes encontrar son diferentes para los distintos tipos de implementaciones de servidor.

Para la integración de listas de espera de reservas, los errores de lógica empresarial se capturan en una falla de lógica empresarial de la lista de espera y se muestran en una respuesta HTTP. Los errores de lógica empresarial pueden ocurrir cuando se crea un recurso, por ejemplo, cuando controlas el método CreateWaitlistEntry. Estos son algunos ejemplos:

• ABOVE_MAX_PARTY_SIZE se usa cuando la entrada de la lista de espera solicitada supera el tamaño de grupo máximo del comercio.
• MERCHANT_CLOSED se usa cuando la lista de espera no está abierta porque el comercio ya está cerrado.

Idempotencia

La comunicación a través de la red no siempre es confiable, y Google puede reintentar las solicitudes HTTP si no se recibe ninguna respuesta. Por este motivo, todos los métodos que mutan el estado deben ser idempotentes:

• CreateWaitlistEntry
• DeleteWaitlistEntry

Para todos los mensajes de solicitud, excepto DeleteWaitlistEntry, se incluyen tokens de idempotencia a fin de identificar de manera única la solicitud. Esto te permite distinguir entre una llamada de REST que se reintentó, con la intención de crear una sola solicitud, y dos solicitudes separadas. DeleteWaitlistEntry se identifica de manera única mediante sus IDs de entrada de lista de espera respectivamente, por lo que no se incluye ningún token de idempotencia en sus solicitudes.

Los siguientes son algunos ejemplos de cómo manejan la idempotencia los servidores de reservas:

• Una respuesta HTTP CreateWaitlistEntry correcta incluye el ID de entrada de lista de espera creado. Si se recibe el mismo CreateWaitlistEntryRequest por segunda vez (con el mismo idempotency_token), se debe mostrar la misma CreateWaitlistEntryResponse. No se crea una segunda entrada de lista de espera ni se muestra ningún error.

  Ten en cuenta que, si un intento de CreateWaitlistEntry falla y se reenvía la misma solicitud, tu backend debería volver a intentarlo.

El requisito de idempotencia se aplica a todos los métodos que mutan el estado.