Implementa el servidor de reservas

Debes implementar un servidor de reservas para permitir que Reserva con Google realice devoluciones de llamada a fin de crear y actualizar las reservas en tu nombre.

• Implementación estándar: Esto permite que Reserva con Google cree citas y reservas contigo en nombre del usuario.

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 reserva de zona de pruebas y producción.

Implementa una interfaz de API de REST

Implementa una interfaz de API basada en REST. Esto le permite a Google enviar solicitudes del servidor de reservas a través de HTTP.

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

Métodos

Para cada tipo de servidor de reservas, debes utilizar un conjunto diferente de métodos de API. También 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 de servicio.

Implementación estándar
Definición de Servicio estándar (Descargar Definición del servicio estándar).

Método	Solicitud 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/

Recursos de la API

Booking

Los siguientes tipos de recursos se usan en la implementación estándar:

• Ranura: Es una ranura de inventario.
• Reserva: Es una cita para un espacio del inventario.

Flujo: Cómo crear una reserva

En esta sección, se explica cómo crear una reserva para la implementación estándar.

Figura 1: Flujo de trabajo para crear una reserva desde un espacio

Cuando un usuario crea una reserva, Google te envía el nombre, el apellido, el número de teléfono y el correo electrónico del usuario. Desde tu punto de vista, esta reserva 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 reserva final sea idéntica a las reservas de tus comercios que provienen de tu sistema de reservas. Los correos electrónicos alternativos y la confirmación de la compra como invitado se admiten de forma predeterminada en las reservas no pagadas.

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 configurar tu servidor, te recomendamos que uses una herramienta de verificación SSL/TLS disponible públicamente, como la prueba del servidor SSL de Qualys.

Todas las solicitudes que Google realice al servidor de reservas se autenticarán mediante el uso de 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 en el Portal para socios. Las contraseñas deben rotarse cada seis meses.

Nota: Debes establecer el nombre de usuario y la contraseña para la zona de pruebas y la producción por separado mediante el Selector de entorno.

Ejemplos de esquemas de implementación

Para comenzar, consulta los siguientes ejemplos de esquemas de un servidor de reservas escritos para marcos de trabajo 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 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 implementación estándar, los posibles errores de lógica empresarial se capturan en una falla de la reserva y se muestran en la respuesta HTTP. Pueden ocurrir errores de lógica empresarial cuando se crea o actualiza un recurso. Por ejemplo, cuando controlas los métodos CreateBooking o UpdatingBooking. Estos son algunos ejemplos:

• Se usa SLOT_UNAVAILABLE si el espacio solicitado ya no está disponible.
• PAYMENT_ERROR_CARD_TYPE_REJECTED se usa si no se acepta el tipo de tarjeta de crédito proporcionado.

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 esta razón, todos los métodos que mutan el estado deben ser idempotentes:

• CreateBooking
• UpdateBooking

En cada mensaje de solicitud, excepto UpdateBooking, los tokens de idempotencia se incluyen para identificar de forma ú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. UpdateBooking se identifica de forma única por sus ID de entrada de reserva 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 CreateBooking correcta incluye la reserva creada. En algunos casos, el pago se procesa como parte del flujo de reserva. Si se recibe exactamente la misma solicitud CreateBookingRequest por segunda vez (con el mismo idempotency_token), se debe mostrar la misma respuesta CreateBookingResponse. No se crea una segunda reserva y se le cobra al usuario exactamente una vez, si corresponde.

  Ten en cuenta que si un intento de CreateBooking falla y se vuelve a enviar 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.