Fundamentos de la API

Creada por Marcello Magalhães, Modificado el Mar., 4 Ago. a las 10:52 A. M. por Marcello Magalhães

La API de Cangooroo está disponible en dos formatos: SOAPREST. Ambos proporcionan acceso a las mismas funcionalidades, permitiéndole elegir el enfoque de integración que mejor se adapte a la arquitectura de su aplicación.

La documentación de cada servicio incluye los métodos disponibles, las estructuras de solicitud y respuesta, así como los parámetros necesarios para la integración.


Endpoint

El endpoint de la API es proporcionado por el operador responsable de la instancia de Cangooroo con la que se integrará su aplicación.

En la mayoría de los casos, la URL base sigue el siguiente formato:

https://ws-[identificacionDelCliente].cangooroo.net

La URL específica y las credenciales de acceso serán proporcionadas durante el proceso de integración.


SOAP

SOAP (Simple Object Access Protocol) es un protocolo de mensajería utilizado para intercambiar información estructurada entre aplicaciones.

Los mensajes SOAP se transmiten en formato XML y normalmente utilizan HTTP como protocolo de transporte. Al ser un estándar ampliamente adoptado en integraciones empresariales, ofrece una alta interoperabilidad entre diferentes plataformas y tecnologías.


REST

REST (Representational State Transfer) es un estilo de arquitectura para el desarrollo de APIs.

Las APIs REST utilizan solicitudes HTTP para acceder y manipular recursos, proporcionando un modelo de comunicación simple, sin estado (stateless) y ampliamente utilizado por las aplicaciones modernas.

Todas las solicitudes y respuestas se intercambian en formato JSON.


Realización de Solicitudes

Las APIs REST se comunican mediante solicitudes HTTP enviadas por el cliente al servidor.

Una solicitud normalmente está compuesta por:

  • Un método HTTP que define la operación que se realizará.
  • El endpoint del recurso solicitado.
  • Encabezados HTTP (Headers) con información adicional de la solicitud.
  • Un cuerpo de la solicitud (Request Body), cuando corresponda.

Métodos HTTP

La API utiliza los métodos HTTP estándar para interactuar con los recursos.

MétodoDescripción
GETRecupera uno o varios recursos.
POSTCrea un nuevo recurso o ejecuta una operación.
PUTActualiza un recurso existente.
DELETEElimina un recurso.
OPTIONSDevuelve los métodos HTTP admitidos por un endpoint específico.

Encabezado Accept

La API devuelve las respuestas en formato JSON.

Aunque actualmente el encabezado Accept es opcional, se recomienda incluirlo en todas las solicitudes para garantizar la compatibilidad con futuras versiones de la API.

Accept: application/json

Ejemplo:

POST https://ws-[identificacionDelCliente].cangooroo.net/API/REST/... HTTP/1.1 
Accept: application/json

Códigos de Respuesta HTTP

La API utiliza los códigos de estado HTTP estándar para indicar el resultado de cada solicitud.

CódigoDescripción
200 (OK)La solicitud se procesó correctamente.
201 (Created)El recurso se creó correctamente.
204 (No Content)La operación se completó correctamente y no se devuelve contenido en la respuesta.
400 (Bad Request)La solicitud contiene parámetros inválidos, errores de validación o una sintaxis incorrecta.
403 (Forbidden)Las credenciales utilizadas no tienen permisos para acceder al recurso solicitado.
404 (Not Found)No se encontró el recurso solicitado.
500 (Internal Server Error)Se produjo un error inesperado al procesar la solicitud.

Formato de Solicitudes y Respuestas

La API REST de Cangooroo utiliza JSON como formato estándar para las solicitudes y respuestas.

Al construir una solicitud JSON:

  • Los valores de tipo texto deben enviarse entre comillas dobles (").
  • Los valores numéricos deben enviarse sin comillas.
  • Los valores booleanos deben representarse como truefalse.

JSON proporciona un formato ligero, fácil de interpretar y compatible con prácticamente cualquier lenguaje de programación.


Compresión GZip

Todos los endpoints de la API admiten compresión GZip.

Se recomienda habilitar esta funcionalidad, ya que reduce el tráfico de red, mejora los tiempos de respuesta y optimiza el uso del ancho de banda entre su aplicación y los servidores de Cangooroo.


Herramientas Recomendadas

Las siguientes herramientas pueden facilitar el desarrollo, las pruebas y el análisis durante el proceso de integración.

Herramientas recomendadas:

  • SoapUI – Pruebas de servicios web SOAP.
  • Postman – Pruebas de APIs REST.
  • Fiddler – Captura e inspección de solicitudes y respuestas HTTP.

Estas herramientas son únicamente recomendaciones y no forman parte del soporte oficial de Cangooroo.

También recomendamos consultar periódicamente las notas de actualización de la API para conocer nuevas funcionalidades, mejoras y cambios.


Autenticación

El acceso a la API está protegido mediante una combinación de credenciales y un token de autenticación.

Dependiendo de la operación realizada, ambos pueden ser necesarios.

Credenciales

Las credenciales son proporcionadas por el operador responsable de la instancia de Cangooroo con la que se integrará su aplicación.

Normalmente están compuestas por:

  • UserName
  • Password

Estas credenciales identifican y autentican su aplicación al acceder a la API.


Token

Además de las credenciales, algunas operaciones requieren un token de autenticación generado durante la consulta de disponibilidad.

Cada vez que se realiza una solicitud de disponibilidad (Availability), la respuesta devuelve un token único asociado tanto a las credenciales utilizadas como a los resultados obtenidos en esa consulta.

Su aplicación debe almacenar este token y utilizarlo durante las siguientes etapas del proceso de reserva para garantizar la consistencia entre la consulta de disponibilidad y la confirmación de la reserva.

Cada respuesta de disponibilidad genera un nuevo token, independientemente del servicio consultado.

Expiración del Token

El token tiene una validez de 30 minutos desde su generación.

Si la reserva no se confirma dentro de ese período, será necesario realizar una nueva consulta de disponibilidad para obtener un nuevo token.


Zona Horaria (Timezone)

Salvo que la documentación de un endpoint indique lo contrario, no incluya información de zona horaria (timezone) en las solicitudes.

Si un método requiere esta información, la documentación correspondiente especificará el formato esperado.

¿Le fue útil este artículo?

¡Qué bueno!

Gracias por sus comentarios

¡Sentimos mucho no haber sido de ayuda!

Gracias por sus comentarios

¡Díganos cómo podemos mejorar este artículo!

Seleccione al menos una de las razones
La verificación de CAPTCHA es obligatoria.

Comentarios enviados

Agradecemos su iniciativa, e intentaremos corregir el artículo