Servidor del socio

Para integrar la información de precios y disponibilidad, los socios deberán implementar la API de Partner. Esta interfaz se basa en REST y permite que Google envíe llamadas en vivo a través de HTTP. Si bien los detalles de los métodos de la API individuales se describen en la sección Referencia, puedes encontrar información sobre los problemas transversales más adelante.

Formato de solicitud y respuesta

Inicialmente, solo se admitirán los formatos JSON. Si necesitas formatos de solicitud o respuesta adicionales, comunícate con el equipo de Transporte de Viajes a [e-mail] para analizar tu caso de uso.

Las solicitudes se enviarán con el método HTTP POST, con el mensaje de solicitud en el cuerpo de POST.

Ten en cuenta que, para mayor claridad estructural, la documentación de la interfaz de la API se proporciona como definiciones de mensajes de búfer de protocolo, y la traducción de una definición de mensaje de búfer de protocolo a un objeto JSON se define mediante el mapeo canónico de JSON, con las opciones para emitir campos con valores predeterminados y para usar nombres de campos .proto en lugar de nombres en lowerCamelCase.

Importante: Se recomienda usar las bibliotecas de búferes de protocolo y las utilidades JsonFormat incluidas para obtener APIs con seguridad de tipos que garanticen que se produzcan respuestas sintácticamente correctas. Las definiciones de enumeración que se muestran en la documentación excluyen el valor de UNSPECIFIED. Estos se deben agregar cuando se usan protobufs directamente.

Autenticación

Google admite la autenticación de resumen HTTP y la autenticación de certificado de cliente. Todas las llamadas HTTP de la API de Partner usan la autenticación de resumen HTTP (con nombre de usuario y contraseña) o la autenticación de certificado de cliente. El socio debe proporcionar a Google un nombre de usuario y una contraseña (consulta Configuración del socio) o un certificado de cliente SSL, respectivamente.

Códigos de estado y control de errores

En general, los siguientes códigos de estado se pueden mostrar en las respuestas HTTP:

HTTP Code	Descripción de HTTP	Notas
😵 *-* x_x	Aceptar	No es un error. que se muestran con éxito. Se espera que el cuerpo de la respuesta contenga un resultado exitoso (p.ej., TripOptionsResult), no una respuesta de error.
400	Solicitud incorrecta	La solicitud recibida no era válida. Las respuestas de error específicas del método deben usarse para devolver detalles adicionales del error en el cuerpo de la respuesta. Por lo general, el error HTTP 400 solo se debe usar si Google cometió un error técnico (p.ej., un campo con un nombre incorrecto en una solicitud).
403	Prohibido	Permiso denegado/prohibido (el emisor es conocido y se rechazó). Esta respuesta no se debe usar para los rechazos causados por el agotamiento de algún recurso (en su lugar, usa Too Many Requests para esos errores). Forbidden no se debe usar si no se puede identificar al emisor (en su lugar, usa Unauthorized para esos errores).
404	No encontrado	No se encontró el recurso solicitado. Las respuestas de error específicas del método se deben usar para devolver detalles de error adicionales en el cuerpo de la respuesta.
429	Demasiadas solicitudes	Se agotó algún recurso, tal vez una cuota por usuario.
500	Error interno del servidor	Errores internos. Esto significa que algunos invariantes que espera el sistema subyacente están rotos. Este código de error está reservado para errores graves y señala un error en la implementación del servidor de la API del socio.
503	Servicio no disponible	El servicio no está disponible. Lo más probable es que esta sea una condición transitoria y que se pueda corregir si vuelves a intentar una retirada.
504	504 Gateway Timeout	El plazo venció antes de que la operación se pudiera completar. En el caso de las operaciones que cambian el estado del sistema, es probable que se muestre este error incluso si la operación se completó correctamente. Por ejemplo, una respuesta correcta desde un servidor podría haberse retrasado lo suficiente como para que el plazo venciera.

Ten en cuenta que, para todas las condiciones previas, los argumentos no válidos o los errores de no encontrado, se aplican las siguientes reglas:

• Se deben usar las respuestas o los mensajes de error específicos del método definidos en las APIs.
• Se debe usar el código HTTP correcto, como se especifica en los códigos específicos del método (consulta, p. ej.,TripOptionsErrorType).

Esto permite proporcionar información más detallada sobre estos tipos de errores. Esta información se puede usar para lo siguiente:

• Determina si se puede volver a intentar un error.
  • No se puede volver a intentar la operación SEGMENT_KEY_NOT_FOUND.
• Corregir la información inactiva
  • Unavailable.Reason.CANCELED indica que se debe quitar el viaje (ten en cuenta que esto forma parte de una respuesta exitosa).
  • Unavailable.Reason.TEMPORARILY_UNAVAILABLE, así como los códigos de error SEGMENT_KEY_NOT_FOUND, SUBOPTIMAL_ITINERARY, BOOKING_WINDOW_NOT_SUPPORTED y TICKETING_PROHIBITED, quitan los precios que recibimos anteriormente de la caché.
• Brinda orientación pertinente a los usuarios

La lista actual de errores específicos del método que se proporciona en TripOptionsError es un punto de partida. Si se necesitan tipos de errores adicionales, comunícate con el equipo de Google Travel Transport.

QPS (consultas por segundo)

Es probable que el nivel de QPS que envía Google varíe según el inventario del socio y la cantidad de usuarios que ven los datos almacenados en caché o hacen clic para acceder a los sitios web de los socios y realizar reservas.

Latencia

Las solicitudes se agotarán después de 10 segundos. No habrá lineamientos adicionales de latencia para las integraciones de socios en versión beta. Sin embargo, se definirán más SLO de latencia en nuestros Lineamientos de calidad de los datos para socios.

Monedas, impuestos y comisiones

Todos los precios que se envían a Google deben incluir todos los impuestos y las tarifas, y especificarse en una moneda admitida.

Moneda

La moneda de un precio se especifica con el campo currency_code, que debe ser un código de moneda ISO 4217 válido.

Ejemplo:10.25 USD

{
  "price": {
    "currency_code": "USD",
    "units": 10,
    "nanos": 250000000
  }
}

Impuestos y tarifas

El precio que proporciones debe ser el precio final y total que pagará el usuario, incluidos todos los impuestos (como el IVA) y las tarifas adicionales (como las tarifas de reserva o de tarjeta de pago). Se puede agregar un desglose de la tarifa opcional con el campo repetible line_items. Google mostrará el precio total con un desglose opcional de la tarifa al usuario.