APIQuality Release Notes
Consulta los últimos cambios y mejoras de APIQuality. Hacemos la herramienta más eficiente cada día.
¿Qué son las release notes?
Las release notes o notas de publicación son una serie de documentos técnicos donde se van indicando las actualizaciones de una herramienta o plataforma.
APIQuality cuenta con esta sección donde se irán publicando las release notes de nuestro integrador de API Tools, mejorándolo cada día para que puedas desarrollar tu APIOps de la manera más eficiente.
¡Consulta las última novedades!
Release notes - Versión 2.21
Se ha añadido el botón de edición del api manager template para poder editar el fichero de configuración antes:
Se ha revisado el editor para que muestre los errores propios del editor y los combine con los errores que puedan venir de sonar / spectral o redocly:
Edición de la configuración de kong
A partir de ahora se permitirá cambiar la configuración de kong antes de hacer el despliegue:
Nuevos campos configurables en el despliegue
Se ha habilitado la configuración del namespace, basepath, targets y tags directamente desde una pantalla para el despliegue:
Configuración de credenciales a nivel de entorno
Se ha llevado la configuración de credenciales a entornos.
Selección de plantillas en el init
Se ha llevado una configuración para que el init de del apigee template pueda coger varias plantillas.
Configuración de base path y target de apigee
Se ha habilitado una pantalla para la configuración del basepath y del target desde un formulario.
Se ha creado mejoras en el ciclo de vida de IBM.
Se añade la extensión IBM vendor en el despliegue de la API
Se añade automáticamente al openapi la extensión de IBM:
Se configura a nivel de organización las propiedades (si se debe ejecutar por repositorio o por fichero).
A continuación se muestran unas imágenes:
Se revisan las reglas de la guía de estilos y los stages para que aparezca una configuración mínima de calidad de la API al crear la organización. Los stages a partir de ahora serán los siguientes:
- Linter
- SonarQube
- Enricher
- OpenAPI Diffs
- Sonar2Spectral
- Microcks
- OpenApi2Postman
- Open API Generator
- Openapi2jmeter
- Newman
- jmeter
- Zap Proxy
Se añade una configuración de gitlab para habilitar los runners y el permiso de crear proyectos en el grupo si no estuviera habilitado.
A partir de ahora se permitirá configurar globalmente en el entorno la parametrización de openapi2postman.
Se han desarrollado las siguientes mejoras de usabilidad:
- Se actualiza el set de reglas de sonar compatibles con spectral.
- Se han mejorado las validaciones al importar para que no se importen ficheros con espacios.
- Se han mejorado algunas traducciones.
- Se ha añadido una verificación de conexión correcta cuando se configura kong en el entorno.
- Se ha mejorado los errores que se muestran cuando se sube un api manager template.
Nuevos stages en Azure
- Kong initializer.
- Kong deployer.
- Kiong validator.
Mejoras:
- Se ha añadido una comprobación para que el openapi-diff no falle la primera vez que se ejecuta
- A partir de ahora no sólo se mostrará dentro del modelo la api sino la rama a la que le hace referencia
- Se ha preconfigurado redocly como –extends= minimal para no obligar a tener seguridad en las apis.
- Se ha añadido una mejora en el stage de configuración de wso2 deployer para que recoja del repositorio y no lo guarde en base de datos la configuración.
- Se ha añadido un campo de comentarios en la configuración del api manager de wso2 para añadirlo al despliegue.
- Se ha comentado la opción de developer portal para crearlos bajo demanda.
- Se ha comentado la opción de descargar el json / yaml resuelto si dicho yaml o json no posee referencias externas dentro del editor de apiquality.
- Se comenta la sección de “accounts” que sólo servía para importar apis desde repositorios.
- Se ha añadido una configuración para que si falla el stage se actualicen los valores del stage en sonar.
- Se ha mejorado el stage de jmeter de Github para subir los reportes a un almacenamiento S3.
- Se ha añadido un enlace para mostrar un vídeo explicativo a la hora de vincular repositorios
- Se ha cambiado la configuración del importer de wso2 para que no sólo importe el swagger sino todo el apiproject.
- Se ha añadido la posiblidad de clonar la plantilla de la ficha.
- Se ha modificado el comportamiento para no autoejecutar los stages de definición cuando se de un error de guardado en el editor de la API.
Fixes:
- Se ha corregido un pequeño error que mostraba el repositorio vinculado y el SaaS al mismo tiempo
- Se ha corregido un pequeño bug que impedía mostrar las líneas del redocly online
- Se ha corregido un bug por el que no se cambiaba alguna configuración de kong una vez establecido los datos
- Se ha corregido el editor de despliegue de Apigee para que coja los datos de la SA para actualizar.
Release notes - Versión 2.20
A partir de ahora se puede configurar fácilmente un ciclo de vida con kong. Para ello, primero hay que activar los stages de kong. Para eso vamos a los entornos y nos creamos un nuevo ciclo de vida:
Después, vamos a añadir los stages de Kong:
Ahora le damos a configurar ejecución:
Aquí debemos poner las credenciales de oauth, el provisioner id, el consumer key y el consumer secret de un usuario de kong con permisos para acceder a la api de administración.
Después, debemos subir la plantilla de la API:
Aquí podemos preseleccionar los plugins que creamos necesario:
Una vez elegida la plantilla y configurado el stage, creamos una nueva API con ciclo de vida Kong.
Una vez creada la nueva api asociada al ciclo de vida de Kong, entramos en la api para configurar y ejecutar los stages. Aquí pulsamos sobre initializer y pulsamos sobre configurar. Debemos seleccionar la plantilla:
Después de inicializar hay que ir al repositorio, para modificar el nombre del servicio y el path.
Se ha creado una nueva funcionalidad que permite securizar los mocks a través del api gateway de apiquality.
Para activarla, hay que ir a Organización->General->Configuración y activar donde pone.
Para obtener la nueva url debemos ir a la API y vemos que la url del mock ha cambiado y ahora aparece una url con api-gateway.XXX.
Para poder invocarlo debemos copiar el apikey que aparece en el principio de la pantalla de configuración e inyectarlo en la cabecera “apikey” para hacer las llamadas. A continuación mostramos un ejemplo con postman:
Para poder reutilizar el mismo jmeter y sólo cambiar los parámetros de ejecución se ha añadido la capacidad de añadir los parámetros típicos de ejecución al importar el jmx en APIQuality.
Con esto, no tendremos que generar varias veces el fichero si no que podremos reutilizarlo y apiquality se encargará de sustituir el puerto, host,hilos, ramp-up, duración y número de casos de prueba.
Se ha creado un nuevo tipo de campo que permite subir ficheros en las oportunidades. Esto permitirá subir tanto documentos como fichas en excel que tenga previamente la organización creadas.
Para eso, hay que ir a templates y crearnos un nuevo campo de tipo “fichero”.
Después, debemos crear una nueva oportunidad seleccionado la template de ficha creada y veremos que se pueden subir 1 o n ficheros que se podrán visualizar de la siguiente forma al consultar la oportunidad:
Se ha añadido una nueva tecnología para generar colecciones de postman. Con Portman, podrás generar colecciones
https://github.com/apideck-libraries/portman
Para poder generar las colecciones, debes activarlo en el entorno de tu ciclo de vida. Te aparecerá en el ciclo de ejecución del entorno de tu api. Ahí, tienes que añadir las colecciones de configuración de postman.
Con esta configuración ya podríamos introducir portman en el ciclo de vida.
Se ha mejorado la configuración del stage de Wso2 para unificar los dos pasos (tenant) y gateways en un único paso de configuración. Además, se ha añadido la posibilidad de modificar el contexto desde el formulario de despliegue simplificado.
Sólo tienes que pulsar sobre configurar y aparecerá la siguiente pantalla:
Aquí puedes guardar directamente esta configuración.
Mejoras:
- Se añade la posibilidad de filtrar por entorno.
Bugs:
- Se ha corregido un bug que impedía la modificación de las credenciales de cualquier API Manager.
Release notes - Versión 2.19
Para el CI/CD de apigee es importante generar los api proxies con un template. Este template se utiliza una herramienta que se llama apigeetemplater (https://github.com/apigee/apigee-templater). Por el momento, se ha implementado la versión v2 dónde se utiliza un fichero de configuración
El fichero de configuración se define por parte de arquitectura y se sube.
En la parte de apimanager templates. Estos templates estarán disponibles para poder configurar los api proxies.
Los perfiles de despliegue que aparezcan en el listado correspondiente serán los que estén disponibles para la configuración. Con eso se quedará configurada para el despliegue.
En esta versión se ha añadido el html del reporte de zap proxy para poder visualizarlo directamente desde la herramienta tal y como se muestra en la siguiente captura de pantalla:
Además, se añade la posiblidad de que se pueda configurar los valores del rating de seguridad. Sólo hay que ir al step de zap proxy, y pulsar sobre “Configure Zap Proxy” y se mostrará la siguiente pantalla:
Se ha creado una nueva funcionalidad que permite saber qué endpoints están testeados y que endpoints están sin testear. Sólo hay que pulsar sobre el botón derecho del stage después de la ejecución de newman y pulsar sobre “view operations tested”.
Aquí se podrá ver la siguiente pantalla además de un % de cobertura:
A partir de ahora se va a poder visualizar los tipos de APIs soportados por cada stage.
Se ha desarrollado una nueva vista con el status de los componentes de APIQuality.
- Sonar2Spectral
- Quality tests – Newman
- Microservices – Apigen ASP.NET
- Definition – Sonarqube
- Definition – Microcks Enricher
- Mocking – Microcks
- Definition – Sonar2Spectral
- Microservices – OpenAPI Generator: JMeter
- Microservices – OpenAPI Generator
- Microservices – Apigen Java SpringBoot
- Definition – OpenAPI Diffs
- Quality tests – JMeter
- Zap proxy
- Apigee X: Init
- Apigee X: Lint
- Quality tests – JMeter
- Deployment in Api Manager – Apigee X
- Newman
- Apigen Java Springboot
- WSO2: Initializer
- WSO2: Deployer
- WSO2: Synchronizer
- Definition – Linter
- Quality tests – Newman
- Microservices – Apigen Java Springboot
- Contract tests – Openapi2Postman
- Mocking – Microcks
- Definition – Sonar2Spectral
- Definition – SonarQube
- OpenApiDiff
- Quality tests – JMeter
- Microservices – Apigen ASP.NET
- ZapProxy
Se ha habilitado un nuevo botón de descarga junto al histórico de pruebas de newman que permite descargarse el informe de pruebas funcionales.
Se ha modificado el aprovisionamiento para que los usuarios con login en sus propios sistemas puedan auto loguearse en la aplicación en un dominio y role específico. En el apartado de configuración de organización nos encontramos el nuevo parámetro.
Esto permitirá cuando te logueas con el sistema externo crearse automáticamente el usuario asignado al dominio y role especificado.
Se ha añadido la posibilidad de conectar con Dashboards de ELK para mostrar la información directamente de las métricas de consumo. Para eso hay que habilitar un parámetro en organización.
Con esto habilita la pestaña de estadísticas dentro de las APIs
Añade la posibilidad de editar los nombres de los modelos. En la pantalla de edición de modelo se ha habilitado una opción dentro de los 3 puntos y aparece una pantalla dónde vamos a poder modificarlo.
A partir de ahora se podrá descargar los API template de Apigee que hayamos subido o editado previamente. En la pantalla de edición de API Manager templates:
Se han cambiado el nombre de las propiedades para que sean más legibles. Si pulsamos sobre los 3 botones sobre el stage de openapi2postman podemos visualizar:
se han realizado las siguientes mejoras:
- Se ha mejorado la recogida de información de los webhooks de azure para mostrar mejor los diferentes estados de la pipeline.
- Se ha añadido la url en la pantallas de configuración de mulesoft en el entorno para facilitar la integración.
- Se permite implementar un mage request para pasar el openapi de rama configurando a nivel de organización en vez de copiarlo y hacer el commit directamente.
- Se añade la funcionalidad de “reintentar el stage” en Azure Devops y Bitbucket.
- Se añade información intermedia de los estados en las ejecuciones con bitbucket.
- Se añade la posibilidad de editar el fichero openapi en varias pestañas.
- Se añade la posibilidad de cambiar el nombre del repositorio.
- Se añade la posibilidad de cambiar el base path por defecto cuando se cambia el nombre de la api.
- Se añade la posibilidad de parar stage para Github.
- Se añade un mensaje de error cuando se va a guardar una api desde el editor y está activo el “resolved” a nivel de organización y existen referencias que no se pueden resolver.
- Se hacen mejoras de usabilidad en el importar api indicando mejor los fallos de importación, como cuando la api ya existe.
Y se han corregido los siguientes bugs:
- Se ha corregido el error del description del commit de los modelos que se mostraban dentro del commit que se visualiza en los repositorios.
- Se ha modificado la aplicación para poder obtener los reportes de newman después de cambiar el nombre del fichero openapi
- Se corrige un bug que impedía descargar el fichero api template.
- Se corrige un bug dentro de la interfaz de edición de api que permite un sólo error.
- Se corrige la ordenación dentro del api explorer por dominios
Release notes - Versión 2.18
Se ha incorporado la posibilidad de importar las APIs directamente desde el APIHUb. Lo primero que tenemos que hacer es habilitar la posibilidad y configurar apigee desde la pantalla de configuración de la organización.
Aquí configuraremos algunos parámetros para poder importar desde Apigee. Una vez habilitado y configurado, podremos ir a importar api dentro de la pantalla de catálogo de la API.
Luego, hay que seleccionar API Hub y seleccionar una de las APIs que están allí para importarlas dentro de APIQuality
A partir de ahora, se podrá ver el histórico de pruebas de seguridad y acceder a los informes que se hayan generado en cada momento.
Sólo tienes que ejecutar la prueba de estrés, y en el botón de “ver ejecuciones”.
Aquí, si pulsamos sobre acciones podremos ver toda la información de la ejecución.
Se ha creado una nueva funcionalidad en el step de pruebas funcionales que calcula que operaciones están testeadas y cuales están sin testear:
Así, podemos saber que endpoints no están probados correctamente.
Se han actualizado Microcks a la versión 1.12 y SonarQube a la versión 10.8 en el SaaS.
Pequeñas mejoras
Se han implementado:
- Se ha añadido la url para la configuración de mulesoft para el shellservice.
- Se ha creado un email para avisar a los administradores de la organización a todos los nuevos usuarios que se registran por primera vez en la plataforma con el sistema de aprovisionamiento.
Bugs
- Se corrige el nombre del usuario en los commits de los modelos
- Se revisan los stages de Newman, Apigen.net, sonarqube, microcks para Azure DevOps
Release notes - Versión 2.17
Se ha creado un MCP server que permite utilizar apiquality como MCP.
Requisitos
- Cuenta creada y activada en APIQuality
- Generar un token a partir de una cuenta https://mcp.apiquality.io/token con la fecha de caducidad deseada (uso actual de autorización, en un futuro puede cambiar).
- Un cliente para usar el MCP (Recomendación Visual Studio Code)
- El cliente debe tener una suscripción a un llm que tenga capacidades agénticas. (Recomendación Google Gemini)
4.1.2. Configuración y uso
Para este ejemplo usaremos Visual Studio Code.
- Generamos un token con la cuenta, password y expiración:
- Si tenemos visual studio code instalado en el dispositivo, podemos pulsar el botón para instalar la configuración generada
- Si se necesita editar de forma manual, esta configuración se aloja en %appdata%\Code\User\mcp.json (Crear si no existe)
- o bien puedes acceder por:
Open Visual Studio Code. Open the Command Palette by pressing Command + Shift + P. Type Developer: Open User Data Folder and select the command from the list. This will immediately open the User folder in a new Finder window. |
ejemplo de fichero mcp.json
{ «servers»: { «ApiQuality»: { «type»: «http», «url»: «https://mcp.apiquality.io», «headers»: { «token»: «apiq_123456» } } } } |
Funcionalidades
GetUserInfoAndOrganizations | Get a user info and organizations |
GetAllUserByOrganizationId | Get all users of an organization |
GetTags | Get tags of an organization |
GetRoles | Get all roles of a user (org. optional) |
GetLoggedUserInfo | Get logged user info |
GetApisInfoByOrganizationId | Get apis info by organization |
CreateApi | Create a new API by uploading a specification file yml or json |
CreateCollection | Create a new Collection |
GetCollections | Get collections |
GetProfiles | Get profiles |
GetApiInfo | Get API info by id |
GetApiRawByBranchId | Get Raw document API by branch id |
UpdateApiDocument | Update API document uploading a specification file yml or json |
Las herramientas listadas pueden variar a las proporcionadas en el servidor, para listar las herramientas operativas consultar la respuestas de comunicación del cliente mcp y activar/desactivar las necesarias.
Ejemplos de uso
Release notes - Versión 2.16
A partir de ahora se va a poder ejecutar las pruebas de seguridad de la api con zap proxy. Por el momento, sólo se podrán ejecutar de caja negra sobre la url que expone la API.
Para ejecutarlo, debemos activar el stage dentro del entorno y ciclo de vida correspondiente.
Una vez activado, debemos pulsar botón derecho en los tres puntos y elegir «Configuración». Aquí, indicamos la URL y la política. Si no nos convence, podemos subir nuestra propia política de ataque.
Una vez configurado, ya podemos ejecutar el stage y esperar a ver los resultados.
El rating se calcula en base a la ponderación de las incidencias y su riesgo. Así, se añade un nuevo rating de seguridad.
Pequeñas mejoras
Se han implementado:
- Se amplía la longitud del path del HOST_URL de postman porque 100 podría quedarse corto.
- Se permite subir varios modelos a la vez
- Se permite el role de api-design-collaborator también en los modelos
- Se añaden todas las opciones de servidor del openapi-generator (Hasta el momento sólo había las 5 principales)
- Se actualiza la versión de node de los stages.
- Se han añadido los tags en el despliegue con wso2 que se añaden en la aplicación, y no los que viene en el openapi.
- Al realizar cierre de sesión para aquellas organizaciones que tienen login propio, el logout se reenviará a la pantalla de login propia.
- Cuando se solicita la validación de las oportunidades para organizaciones que tienen implementado el login, el correo debe redirigir al login propio y no al login normal. Por ejemplo: https://app.apiquality.io/<organizacion>
- Se añade la información de los stages de tyk.
- Mejora de rendimiento en la pantalla de visualización de una api.
Bugs
- Se valida que no se pierda el nombre API al cambiar de un paso a otro dentro de las oportunidades
Release notes - Versión 2.15
Por fin, Tyk pasa de los custom stages (bajo demanda) a tener el ciclo de vida oficial implementado en APIQuality. Se han desarrollado los siguientes 3 steps:
- Tyk: Initializer. Crea el proyecto para ser desplegado en Tyk.
- Tyk: Deployer. Despliega el proyecto en Tyk.
- TyK: Synchronizer. Sincroniza lo desplegado dentro del propio Tyk.
A partir de ahora el step de retrocompatibilidad mostrará visualmente el api change log indicando por qué se rompe la compatibilidad dejando un histórico de api change log.
Para eso, hay que habilitar el step “OpenAPI Diffs” que comprueba la retrocompatibilidad. En esta pantalla, mostrará los cambios que han ido ocurriendo en las modificaciones de la API. Dentro de acciones, podemos pulsar sobre el icono de «Ver», y poder comprobar el api change log.
Se instala el último plugin de sonar rules liberado por la fundación APIAddicts (https://github.com/apiaddicts/sonaropenapi-rules) con las siguientes nuevas reglas:
- OAR103 – ResourcesByGetVerb – Get Operation not recommended for resource path
- OAR104 – ResourcesByPostVerb – Post Operation not recommended for resource path
- OAR105 – ResourcesByPutVerb – Put Operation not recommended for resource path
- OAR106 – ResourcesByPatchVerb – Patch Operation not recommended for resource path
- OAR107 – ResourcesByDeleteVerb – Delete Operation not recommended for resource
- OAR108 – SchemaValidator – Schema does not match the provided example. The schemas should match the provided examples
- OAR109 – ForbiddenInternalServerErrorCheckTest – Use default instead of directly specifying 5XX codes
- OAR110 – LicenseInformation – License information cannot be empty
- OAR111 – ContactInformation – Contact information cannot be empty
Hasta el momento, la ejecución de las pruebas funcionales se tenía que realizar subiendo el fichero en el step de newman. A partir de ahora, se podrá configurar para que se ejecuten directamente desde una carpeta del repositorio:
Primero, se deberá configurar que la ruta del repositorio se recoja de las propiedades de la organización.
En estas propiedades, ponemos la ruta de los ficheros y vemos que debemos subir las colecciones de postman y environments a esta ruta:
Cuando ya esté configurado tanto en la api como a nivel de organización podemos ejecutar directamente. Podremos ver cómo se ha ejecutado y que se ha hecho correctamente.
A partir de ahora, además de APIs y fichas se mostrarán los modelos que se hayan subido a la plataforma.
Se ha añadido al stage de openapi generator la opción de generar pruebas de estrés con K6. Con esto, podremos generar la base para poder ejecutar pruebas de estrés con esta tecnología.
Se ha mejorado / corregido:
- Se habilita la posibilidad de ejecutar manualmente los stages.
- Se ha habilitado el reporte de redocly, Sonar2Spectral, Microcks y Openapi2Postman.
- Se ha corregido un fallo por el que al activar / desactivar algunos parámetros de organización daban un error 500.
- Se ha habilitado la funcionalidad de poner bloqueante los steps.
- Se ha corregido un fallo que daba al editar la definición de la API
Release notes - Versión 2.13 y 2.14
A partir de ahora, se ha desarrollado el ciclo de vida de pruebas de estrés desde la generación de los tests como la ejecución y el histórico.
Lo primero que hacemos es añadir el step “openapi generator Jmeter” que utiliza la herramienta openapigenerator para la generación.
Una vez generado el step, podemos o bien clonar el repositorio o bien descargarlo a local para configurar en jmeter las pruebas. Luego, se importa el archivo jmeter.
Una vez que tienes configuradas las pruebas, puedes subirlas en otro step que se llama “Quality tests -JMeter” dónde tenemos que subir un fichero y el csv de datos.
Después de ejecutar el step, podemos ver el histórico de ejecuciones.
Aquí podemos ver la media de latencia, el throughput, los errores y podemos acceder al informe más detallado.
Para facilitar las migraciones se ha añadido una opción que permite importar las APIs directamente desde Wso2. Para ello, hay que configurarlo a nivel de organización.
A partir de ahí, si vamos a importar una API en la pantalla de catálogo, aparecerá dentro de source “wso2”. Si seleccionamos esta source, se mostrarán las APIs para que elijamos cual queremos importar. Si la seleccionamos veremos que se importa correctamente.
Se ha generado una nueva pantalla que permite dotar de más funcionalidad a los modelos.
Vemos que la nueva pantalla es muy parecida a la que existía de APIs. En el listado mostrará si el modelo ya está enlazado a una API.
Al darle a visualizar vemos que aparecen 3 pantallas, una general, dónde se mostrará la información del modelo, otra de APIs (las apis que enlazan el modelo) y otra de auditoría (para saber quién ha ido modificando el modelo).
En la parte general se mostrará la siguiente información: nombre del modelo, fichero, dominio al que pertenece el modelo, versión, url de referencia y una opción para subir directamente el fichero.
En auditoría se mostrará la fecha de creación y la de la última actualización.
En la pantalla de APIs se muestran las APIs que están enlazados al modelo.
Esta pantalla permite visualizar las modificaciones que se han ido realizando en los modelos. Para poder acceder se debe pulsar sobre el botón audit disponible en el listado de modelos. A continuación, se mostrará la siguiente información:
- Modelo
- Acción
- Descripción
- Usuario
- Fecha de la auditoría
Se ha añadido un nuevo step para generar código con la herramienta de openapigenerator.
Una vez añadido el step dentro del entorno, al pulsar sobre ejecutar aparecerá la siguiente pantalla:
Aquí se podrá seleccionar el lenguaje a generar. La generación se dejará dentro del repositorio de la API y también se dará la opción de descargarlo desde el local.
Si queremos descargarlo se habilitará una opción de “descargar arquetipo” dónde podremos descargarlo al local.
Los pipelines a veces pueden tardar un poco y los desarrolladores tienden a estar “refrescando” la pantalla para revisar si ha terminado el proceso o no. A partir de ahora, se ha añadido un botón a la derecha para que refresque la información de los steps.
Pequeñas mejoras:
- Se ha añadido un control en la pantalla de generación con IA para asegurar que el usuario guarda primero la API antes de generar la API.
- Se ha añadido un vídeo explicativo que muestra como se puede configurar github con apiquality para facilitar la integración.
- Nuevo campo “instrucciones fixed” en las oportunidades que actúa como los campos “fixed” que se pueden añadir a la plantilla y no se pueden modificar.
- Nuevo campo “text editable” que permite separar generador de campos con “guiones”.
- Se ha implementado una mejora para mostrar los reportes de las APIs en aquellas ramas que no son develop.
- Se ha implementado el envío de email para el ciclo de vida de aprobación de la oportunidad.
- Se ha mejorado el stop para cancelar la pipeline. Actualmente sólo se cancelaba si se podía cancelar dentro del repositorio. En este caso, se cancelará independientemente si en el repositorio se puede cancelar o no.
- Se ha añadido el nombre del perfil de despliegue en la pantalla de ejecución del entorno.
- El perfil de apidesign-collaborator puede crear nuevas ramas y actualmente el patrón era fijo. Se ha mejorado para que sea configurable a nivel de organización.
- Se ha añadido el step de newman en bitbucket server para que funcione correctamente.
- Ordenar las ejecuciones de newman para que salgan por orden cronológico inverso.
- Limpiar los steps de la api cuando se cambie de entorno. Se ha realizado una pequeña mejora de usabilidad que permite limpiar los steps en cuando cambiemos de entorno, así no parecerá que son los mismos mientras se tarda en cargarse los nuevos.
- Se ha mejorado la visualización de la ficha para que tenga en cuenta los campos calculados.
Fixes:
- Se ha corregido un fix que no permitía visualizar correctamente las incidencias de redocly en el editor online ni en el reporte de la API.
Release notes - Versión 2.12
A partir de ahora las APIs que se desplieguen en Wso2 tendrán una información adicional que será la del despliegue. Esta información aparece en la sección de «Despliegue», dentro de «Deployment».
Muestra el tenant dónde está desplegado, alguna configuración y las aplicaciones que la consumen.
Se han diseñado los stages que serán la base de la automatización del Apigee dentro de APIQuality. Por el momento, sólo estarán bajo demanda y se habilitarán como custom stages.
Los stages implementados son los siguientes:
- Openapi2apigee: Permite generar el esqueleto del API PRoxy a partir de la api.
- Apigee-templater: Permite generar el esqueleto del API Proxy incluyendo políticas
- apigeelint: Permite validar que el documento es válido.
- apigeecli: Permite desplegar en Apigee
Actualmente, si modificabas un stage general se creaba un stage de organización, lo que hacía que nunca supieses si ha habido evoluciones o mejoras sobre ese stage. A partir de ahora, podremos saber si ese stage ha sido modificado desde la pantalla de entornos tal y como se muestra en la siguiente figura:
Desde esta ventana podremos actualizar el stage directamente desde el botón update.
Pequeñas mejoras:
- Se ha quitado la autoejecución de steps después de importar una API
- Se ha habilitado la posibilidad de editar el nombre de la API
- Se ha añadido paginación a los modelos
- Se ha realizado una mejora en el generador de custom stages que inserta automáticamente el nombre del stage en el stage, y así facilitar la ejecución.
- Se ha añadido la funcionalidad de enviar emails con el motivo de aprobación o rechazo de la ficha de la API.
- Se ha añadido el nombre del usuario en el commit del stage de JAPI
- Se ha modificado la pantalla de planes de apiquality para que se visualice correctamente los planes y cómo eliminar la organización.
Fixes:
- Se ha corregido un fix que impedía que se pintase los errores de redocly en el api designer
- Se ha corregido el rating de la API para que fuera la media de los ratings de los steps
- Se ha corregido un fix que generaba un fallo al generar la rama v2 en la ejecución de los pipelines.
- Se ha corregido un fix por el cual al descargar el yaml se añadía un carácter extraño en la línea 1.
- Icono de se necesita configuración en un stage. Se ha corregido para que sólo salga si no se ha configurado el stage por primera vez.
- Se ha corregido para que se puedan crear guías de estilos desde cero.
- Se ha corregido un pequeño fix que impedía a las APIs ejecutarse en Azure Devops
Release notes - Mayo 2025 (versión 2.11)
A partir de ahora se ha desarrollado un flujo simplificado para los despliegues de Mulesoft. Se han creado los siguientes stages:
Mulesoft: Syncronizer-DesignCenter
Permite sincronizar una api modificada en el design center
Mulesoft: Deployer-Exchange
Permite subir al Exchange una API
Importar API
Si está habilitada la configuración de Mulesoft en la organización se podrá importar una API.
Se podrá importar masivamente usuario vía CSV. Sólo hay que descargarse el csv de ejemplo,
y completarlo con los usuarios que se quieren dar de alta. Si el fichero viene con algún error saldría la siguiente pantalla:
Cuando esté bien correctamente se enviará las invitaciones a los usuarios:
Se han creado los nuevos campos:
Instructions:
Permite introducir un campo de instrucciones.
Calculated field:
Permite calcular campos que son la suma de dos campos calculados.
Calculated text field
Permite combinar campos del formulario junto con texto.
Calculated editable field
Permite combinar campos del formulario junto con texto pero editable.
Fixed
Campo fijo para la opportunity.
Organization properties
Se ha añadido un nuevo campo que permite añadir propiedades a nivel de organización.
Se ha habilitado la posibilidad de editar las guías de estilos y asignarle una nueva guía de estilos. En el menú de dominios, al editar un dominio nos dará la posibilidad de cambiarlo:
Dentro del menú General, hay una opción de properties. Al pulsar sobre properties podemos crear y editar nuevos espacios de propiedades.
Al pulsar dentro del namespace podemos gestionar sus propiedades:
Aquí se pueden crear las propiedades.
Estas propiedades se pueden añadir en las ficha / oportunities de las APIs.
Pequeñas mejoras:
- Se ha modificado el role de api designer collaborator para que puedan editar y guardar apis.
- Se ha añadido un campo de información dentro de los steps que permite saber qué hace cada step.
- Se actualiza la pantalla de la APi después de hacer una promoción de la API para que pueda actualizar la versión.
- Se ha añadido el icono de advertencia en el stage de newman cuando no tiene configuración.
- Se ha corregido la pantalla de easy deploy de wso2 para que sólo muestre los gateways del entorno.
- Se ha mejorado las ordenaciones de la vista de oportunities/fichas.
- Se ha cambiado la generación del reporte de redocly para permitir su descarga en organizaciones con bitbucket
- Se ha cambiado la descarga de openapi2postman para repositorios con bitbucket
- Se ha habilitado la posibilidad de crear nuevos dominios en organizaciones con bitbucket.
- Se ha modificado la generación de colecciones de openapi2postman para que el nombre del fichero indique el entorno.
Fixes:
- Se ha corregido fallos de ejecución manual
- Se ha corregido el botón de retry de sonarqube que no estaba funcionando.
- Se ha corregido una incidencia por la que al borrar las preguntas de un paso se eliminaban las preguntas del resto de pasos de una ficha.
- Se ha corregido para que no falle el modificar dominio.
- Se ha corregido para que no de error de pantallazo gris al modificar los stages de posición en la pantalla de entornos.
Release notes - Mayo 2025 (versión 2.10)
Se ha habilitado la integración con el repositorio de Github.
A partir de ahora, se podrá utilizar Github como repositorio base. Para eso, se tendrá que vincular en la parte de repositorios.
Los datos se pueden obtener siguiendo el siguiente vídeo explicativo: https://www.youtube.com/watch?v=ym44IpxTGZ0
Después, ya podremos importar una API como con cualquier otro repositorio.
Se ha creado una nueva funcionalidad que permite aprobar o rechazar las fichas desde APIQuality. En la pantalla de configuración de organización, se puede activar la aprobación de oportunidades.
Además, también se puede restringir que sólo se puedan crear APIs con fichas aprobadas.
Ahora, en el listado de fichas / oportunidades vemos que aparece un símbolo de enviar aprobación de la ficha.
Esto permitirá enviar la petición de aprobación al responsable tanto por las notificaciones internas como por email notificaciones internas:
Y se mostrará en la tabla pendiente de aprobar:
El aprobador deberá entrar en la ficha y aprobarla o rechazarla. Si la rechaza deberá indicar el motivo de rechazo:
Se han implementado las siguientes nuevas reglas:
- Regla OAR003 – DefinedWso2ScopesDescription
- Regla OAR002 – ValidWso2Scopes
- Regla OAR004 – ValidWso2ScopesRoles
- Regla OAR005 – UndefinedWso2ScopeUse
- Regla OAR040 – StandardWso2ScopesName
- Regla OAR041 – UndefinedAuthTypeForWso2Scope
- Regla OAR043 – ParsingError
- Regla OAR090 – RefResponse
- Regla OAR108 – SchemaValidator
Se ha habilitado un nuevo parámetro por organización que indica que Newman recoge los ficheros desde una carpeta del repositorio. Si se habilita a nivel de organización:
y se configuran las properties a nivel de API:
Se puede ejecutar sin necesidad de subirlo a mano los ficheros de environments y collections:
En el editor online se ha activado una función de markdown que permite visualizar los markdows de forma “pretty”.
Se crea la opción de generar external stages con funcionalidad externa de organizaciones. En este caso, se ha realizado la integración de la herramienta JAPI Mapping para la generación de microservicios que permite mapear visualmente campos de un OpenAPI a campos de la base de datos.
Se han implementado:
- Se ha añadido la posibilidad del stage de openapi diffs para la retrocompatibilidad de que sea bloqueante.
- Se ha creado una nueva posibilidad de parámetro de organización de poder crear nuevos entornos (para ramas)
- Se ha creado un parámetro global que permite desactivar el autoversionado de la API cuando se edita en el editor online.
- Se le da permisos al API designer collaborator para que tenga permiso para crear ramas feature de una API
Release notes - Abril 2025 (versión 2.9)
Acabamos de incorporar TyK dentro del ciclo de vida de APiquality y pronto podréis tener
un ciclo de vida completo dentro de la plataforma.
A partir de ahora se van a poder configurar los steps como secuenciales, manuales o
ambos. Esto hace que el botón de “play” pasa a hacer una ejecución de todos los steps
que están definidos como secuenciales.
Para configurarlo, debemos de ir a la pantalla de entornos:
Si pulsamos el icono de configuración:
Y aquí podemos seleccionar el tipo de step.
Para después poder ejecutarse en el play.
Se han implementado en spectral las siguientes reglas:
– Regla OAR002 – ValidWso2Scopes
– Regla OAR003 – DefinedWso2ScopesDescription
– Regla OAR004 – ValidWso2ScopesRoles
– Regla OAR005 – UndefinedWso2ScopeUse
– Regla OAR040 – StandardWso2ScopesName
– Regla OAR041 – UndefinedAuthTypeForWso2Scope
– Regla OAR043 – ParsingError
– Regla OAR090 – RefResponse
– Regla OAR108 – SchemaValidator
Se han realizado los siguientes cambios menores:
– Se ha eliminado la autoejecución al importar la API.
– Selector de fichero de la API. Si por algún cambio de nombre o de extensión se
quedase desincronizado ahora se puede cambiar directamente desde la
aplicación.
– Se añade en la configuración de la organización la capacidad de crear nuevos
entornos directamente desde la API.
– Se ha creado una exclamación para indicar que hay stages sin configurar
– Se añade la visualización online de markdown dentro del editor online
– Se ha añadido la posibilidad de desplegar en varios gateways para wso2
– Se ha cambiado configuración del sonar project para que el id de proyecto no
venga con la rama y venga como variable de entorno.
Se ha resuelto el problema que no sincronizaba bien las api categories con
el api.yaml para despliegues de tipo wso2.
– Se ha resuelto un problema que mostraba todos los gateways al desplegar
en wso2 independientemente del entorno.
– Se ha resuelto la pantalla gris de rating en entornos que no tenían rating.
– Se ha arreglado para que se ejecute el stage de apigen.springboot
– Se ha resuelto un bug que impedía clonar guía de estilos
– Se añade la posiblidad de que newman sea un stage bloqueante
Release notes - Marzo 2025 (versión 2.8)
Se ha creado una nueva pantalla para ordenar los entornos. Para diseñarlo se debe ir a Settings -> Environments y aparecerá la siguiente pantalla:
Aquí se podrá diseñar el orden de los entornos según el perfil de despliegue.
Este orden se utilizará para los pasos de entorno. Para eso, se podrá pasar el openapi sólo de un entorno a un entorno previo. Para eso, se puede ir en la pantalla de visualización de una api.
En los promotions de cada api manager también se deberá seleccionar el entorno previo.
Se han añadido filtros de búsqueda para los listado de fichas/contexto de APIs. A continuación se muestra la nueva pantalla:
A partir de ahora, sólo se mostrará por defecto el path y descripción del mismo. Si queremos añadir una operación quedará como un añadido.
Se ha cambiado la pantalla de visualización de la api para que tenga varias pestañas (general, properties y auditoría) para que se empiece a ver la información de forma más limpia.
Las propiedades de las APis se inyectarán dentro del CI / CD de los steps.
Se ha separado los errores de definición con los de seguridad basados en definición en la pantalla de rating de la API:
Pantalla de visualización de definición de la API:
Pantalla de visualización de errores de definición de seguridad
Se han añadido nuevas funcionalidades de generación de pruebas para postman:
Las nuevas opciones son las siguientes:
- Validate Schema: Valida la salida de la información de la API cumpla con el openapi.
- Generate oneOf/anyOf: Crea una prueba para cada opción de oneOf/anyOf que esté diseñada en el openapi
- Minimal Endpoints: Crea una prueba por cada código de error de respuesta y no una prueba por cada filtro, parámetro requerida de entrada…
- Host server pattern: Obtiene el parámetro host según el pattern que se ha diseñado en el parámetro dentro de la opción de servers del openapi.
A partir de ahora, si activas este parámetro mostrará los errores de redocly en el editor online:
Al activarlo aparecen los errores de validación de redocly en el editor online:
- Error al generar el openapi on IA. A partir de ahora si el contexto de salida es demasiado grande con IA se mandará un mensaje al usuario.
- Después de promover la definición entre entornos se actualiza automáticamente la página para que no se quede información de la API obsoleta.
- Desbordamiento de decimales en el índice de mocking. Se ajustan los decimales para que se vean correctamente.
- Permite modificar opportunities / contexto de la API aunque ya esté enlazada a una API.
- Se cambia de orden el microcks enricher para que no se cambie el openapi después de ejecutar el sonar y así hacer coincidir las líneas con los errores / warnings de definición.
- No se está actualizando los openapi con resolución de ficheros externos.
- Se ha resuelto un error por el que se descargaba la guía de estilos completa y no la guía de estilos configurada.
Release notes - Febrero 2025 (versión 2.7)
Cuando la API se enlaza con la ficha se ha añadido una pantalla de visualización:
Si se pulsa sobre el icono de ficha se mostrará la ficha en una sola pantalla:
Por defecto sigue validándose con sonar, pero a partir de ahora se podrá validar elegir si validamos con spectral o sonar en el editor online gracias a un nuevo parámetro de configuración.
A partir de ahora, se podrá visualizar el histórico de ejecuciones de las pruebas funcionales.
Si ejecutamos varias veces newman, vemos como se va a ir cargando.
Al pulsar sobre “Ver ejecuciones” se mostrará un histórico de las ejecuciones realizadas en newman
Se ha añadido un botón que permite descargar la API desde la pantalla de visualización de la API.
Se ha añadido un nuevo step de pruebas de calidad para ejecutarse después de los despliegues del api manager.
En la pantalla de configuración de entornos se puede activar el step:
Y después vemos como se ejecuta después de los despliegues en Newman:
Se han implementado las siguientes reglas en spectral:
- OAR101 – FirstPartBasePath – The first part of the path should be one of the alloweds
- OAR082 – BinaryOrByte – The string properties of the specified parameters must define a byte or binary format.
- OAR102 – SecondPartBasePath – The second part of the path should be one of the alloweds
- OAR035 – AuthorizationResponses – When defining security schemes, authorization response codes must be defined
- OAR069 – PathParamAndQuery – Any param in PATH or QUERY, should have bad request (400) response
Release notes - Enero 2025 (versión 2.6)
Se ha cambiado el editor online para que se utilice spectral y redocly en tiempo real y así no haya que esperar a la ejecución de las tareas de APIOps.
Estos errores serían los mismos que se visualizaran en local si utilizamos un IDE con spectral:
A partir de ahora, se visualizará el dominio al que pertenece la API dentro de la pantalla de visualización de API.
A partir de ahora, la pantalla de visualización de apis estará paginada.
A partir de ahora, se puede actualizar los templates de los api managers. Hay que ir a API Manager templates, pulsar sobre editar:
Y aparecerá la pantalla de edición del template:
- OAR102 – SecondPartBasePath – La segunda parte de la ruta debe ser una de las permitidas
- OAR035 – AuthorizationResponses – Al definir esquemas de seguridad, deben definirse códigos de respuesta de autorización
- OAR069 – PathParamAndQuery – Cualquier param en PATH o QUERY, debe tener respuesta bad request (400)
Se va a añadir una nueva sección de pruebas con el step de newman para poder añadir la ejecución de pruebas funcionales después de los despliegues.
- Se ha corregido un error que impedía subir en algunos casos las colecciones y environments para newman
- Se ha corregido el error que mostraba todas las ejecuciones de newman en el árbol de ejecución en la pantalla de visualización de una api
- Se ha corregido la incidencia por la que el tutorial de configuración de una organización había que saltarlo varias veces.
- Se ha corregido el problema que existía al quedarse en gris la pantalla después de añadir usuarios a un entorno.
- Se ha corregido el problema de que aparecían las notificaciones de todas las organizaciones del usuario en el icono de notificaciones.
Release notes - Diciembre 2024 (versión 2.5)
Se ha mejorado el algoritmo para que coja el api-template, la guía de estilos de spectral y el formulario de entrada para generar la API.
Para generar la API con IA, debemos de crear una oportunity con un atributo de tipo path, como el siguiente:
En esta pantalla, hay una nueva opción para crear APIS con IA, que permite seleccionar el api template para meterlo dentro del contexto:
Aquí se puede ver la nueva api que ha generado la IA.
APiquality permite utilizar tus propios repositorios, sonarQube y microcks. Para indicarlo mejor, se ha habilitado unas pantallas dentro de Config-> repositories dónde podemos ver lo que tenemos configurado y lo que se podría configurar.
Aquí se puede configurar el resto de repositorios. Si pulsamos sobre servicios, podemos enlazar nuestro propio microcks y nuestro propio sonarqube.
Al configurar openapi2postman podemos indicar que valores de datos queremos que nos genere automáticamente en los ejemplos de successful y en los de error. Por lo tanto, si vamos a la pantalla de edición de la API y pulsamos sobre el step de opeanpi2postman y sobre advance configuration, podremos cambiar dichos valores:
Estos valores sólo se usan cuando indicamos que los valores no se van a poner “inline” si no que se van a poner en los entornos. Así, se creará un entorno con los siguientes datos:
Se han añadido una serie de properties asociadas a los dominios que permitirán poder mejorar la configuración de los pipelines.
Además se puede crear properties asociadas a los api managers, en este caso para wso2, se pueden definir los tenants, api categories y los gateways.
Esta información será utilizada para desplegar dentro de los api managers, en este caso en Wso2.
Para la configuración de los distintos api managers, se ha creado una pantalla de api manager templates. Si pulsamos sobre settings -> api manager templates podremos subir las plantillas de configuración que se podrán usar.
Esta información será utilizada para los stages de api managers.
A continuación nos permite elegir el template a utilizar:
y a partir de aquí ya podemos ejecutar el stage para preparar el proyecto.
El initializer coge el openapi y el template de proyecto y genera una configuración de proyecto personalizada.
Para los usuarios menos avanzados se ha creado un formulario rápido de despliegue que seleccionado pocos datos permita un despliegue. Sólo tenemos que editar la configuración del api manager del stage de “Wso2:deployer”
y aquí ir configurando los pasos. En el paso 1 configuramos el tentant:
En el paso 2, configuramos los gateways, api categories y los endpoints:
Con todo esto ya estamos listos para desplegar en nuestro api manager.
Se han implementado las siguientes reglas de Sonar en spectral:
- OAR076 – NumericFormat – Numeric types requires a valid format
Release notes - Diciembre 2024 (versión 2.4)
A partir de ahora, las incidencias de redocly van a estar disponibles en el linter online igual que estaban las de sonarAPI. Para poder verlo, sólo tienes que tener el stage de redocly linter activado, haber pasado dicho linter para que te muestre las incidencias.
Para acceder al editor online se realiza desde la pantalla de visualización de una API, botón derecho sobre el stage de redocly o sonar, editar API.
Esta opción nos lleva a la pantalla del editor online:
Las incidencias que están indicadas como “Redocly XXX” son las incidencias del linter.
A partir de ahora, se han creado 3 steps de Wso2 4.2 y 4.1 para completar el ciclo de vida.
WSO2: Initializer
Permite inicializar al ap project que utilizaremos para desplegar. Para poder activar vamos a la pantalla de entornos, y lo activas. Al darle a configurar nos saldrá la siguiente pantalla:
El usuario y password deben ser de un usuario de permiso devops. La url debe ser la url de /oauth/token del api manager y la versión del mismo.
Después, tenemos que ir a la ventana de ciclo de vida de la API y ejecutarlo, lo que creará un api.yaml con la configuración inicial del openapi.
WSO2: Syncronizer
Este stage permite sincronizar la información disponible de la API dentro de Wso2. Para activarlo se debe ir a entornos, wso2:syncronizer y activate. Después, hay que darle a configurar. Se pre-cargará la pantalla de configuración:
Después, se podrá ejecutar en la pantalla de ejecución:
Esta pantalla sincronizará la información de despliegue que está actualmente en el api manager. Para comprobarlo, podemos ir al fichero de la API, dónde veremos que se han añadido algunos campos propios de WSO2, x-wso2-cors, x-wso2-production-endpoints.
WSO2: Deployer
Este stage permite desplegar en wso2 api manager tanto la versión 4.1 y 4.2. Para desplegar, se debe activar en la pantalla de entornos:
y después de debe configurar el stage:
Para ejecutarse, primero habrá que configurar el api.yaml de configuración de proyecto. La primera vez debemos ejecutar el initializer, para que nos cargue un fichero api.yaml propuesta.
Al pulsar sobre “Edit API Manager” aparecerá la pantalla de configuración del api manager dónde se podrán modificar los valores de despliegue.
WSO2: Environment promotion
Este stage permite promocionar la información de Wso2 entre 2 entornos. Se debe ejecutar en el entorno destino. Para activarlo se debe activar desde la pantalla de configuración de entornos:
Después, se debe ejecutar desde la pantalla del ciclo de vida:
Si pulsamos sobre edit api manager en wso2 deployer:
Podemos ver la configuración que nos hemos traído de validación. Ahora ejecutamos el despliegue en el entorno de producción.
Se mejora la usabilidad de la pantalla de reports para que sea más fácil ver todos los errores de una vez. Ahora, aparecerá todos los apartados cerrados y con un resumen de warnings y errores.
A partir de ahora, se notificará el resultado positivo o negativo de cada ejecución. Se podrá notificar lo que queremos que nos notifiquen en la pantalla de configuración de notificaciones.
Aquí nos saldrá la pantalla de configuración:
Dónde podremos indicar si queremos que nos notifiquen los que han ido bien, los mal o todos.
A continuación se muestra un ejemplo de notificación por email:
A partir de ahora, se muestran en amarillo los stages que necesitan una configuración después de activarlos.
A continuación se muestra la tabla de nuevas reglas implementadas en spectral:
Regla | Descripción |
OAR051 | DescriptionDiffersSummary – Operation description must differ from its summary. |
OAR031 | Examples – Responses, Request Body, Parameters and Properties must have an example defined |
OAR037 | StringFormat – String types requires a valid format |
OAR034 | StandardPagedResponse – Paged response schema must be compliant with the standard |
Release notes - Noviembre 2024 (versión 2.3)
Se ha añadido un nuevo stage que permite revisar si el cambio está rompiendo la retrocompatibilidad y bloquear el despliegue. Para activarlo hay que ir a entornos y activarlo como otro stage.
A partir de ese momento si el stage rompe la compatibilidad se pondrá un aspa en rojo:
y si no lo rompe seguirá en verde.
Para ver por qué ha roto la compatibilidad podemos ver los logs:
A partir de ahora se podrá cambiar de dominio una API. Hay que tener cuidado porque además del dominio se cambia el grupo al que pertenece dentro del repositorio.
Para mover una API hay que ir a la pantalla de visualización de una api, pulsar sobre los tres puntos que hay en la línea de despliegue y seleccionar Move To new domain:
A continuación se mostrará una nueva ventana con los dominios disponibles:
Al pulsar sobre el botón de update la api cambiará automáticamente de dominio.
Para poder promocionar la definición de la API a otro entorno debemos seleccionar el entorno destino, ir a la pantalla de visualización de la API y ejecutar la operación “mover definición al entorno”.
A continuación mostrará una pantalla para que seleccionemos el entorno del que queremos recoger la definición:
Al seleccionar merge la definición del nuevo entorno será la definición que existía en el entorno origen (en este caso, hemos movido a producción la definición de desarrollo).
A partir de ahora, los usuarios podrán suscribir a las ejecuciones de las pipelines. Se podrán suscribir al dominio entero o a la API.
Configuración de las notificaciones: en la campana de notificaciones se puede configurar si deseamos las notificaciones por la web o por email. A continuación se muestra una imagen:
Al pulsar sobre el botón de configuración saldrá la siguiente pantalla:
Aquí se puede activar o desactivar las notificaciones e indicar el canal por la que deseamos recibirlas. Además, se puede ver los elementos que actualmente estamos suscritos.
- Notificaciones del dominio:
para activar las notificaciones del dominio debemos ir a la pantalla de visualización del dominio y darle a follow, tal y como se muestra en la siguiente pantalla:
A partir de entonces todos las ejecuciones de pipelines serán notificadas al usuario.
- Notificaciones de la API:
para activar las notificaciones a una API se debe ir a la pantalla de visualización de una API y pulsar sobre el icono de follow, tal y como se muestra en la siguiente pantalla:
Se ha mejorado la usabilidad de la pantalla general dónde se muestra la suscripción como los parámetros generales de la organización. A partir de ahora, existirán 2 pestañas que permitirá visualizar mejor la información, pudiendo filtrar por los parámetros del sistema. A continuación se muestran las dos pantallas:
Para poder generar la API de una forma ágil, se ha desarrollado una pantalla de generación de operaciones dónde sólo hay que introducir el nombre de las propiedades, y la IA propondrá un diseño de la API. Hay que tener en cuenta que es importante que la guía de estilos esté bien y que exista una api_template dentro dela organización, puesto que se pasarán como contexto para la generación de la nueva API.
Para poder completar este formulario, hay que diseñarlo dentro de la parte de oportunities. Con el perfil de administrador o de arquitecto de la API, se debe generar un nuevo template de oportunities.
Se debe crear una pregunta que sea de tipo path y cuya repuesta sea de tipo formulario, tal y como se puede ver a continuación:
Al pulsarlo ya tendremos la ficha de operaciones para poder crear la API.
Los perfiles que pueden crear APIs también pueden crear oportunities, por lo que en la pantalla de oportunities pueden pulsar sobre crear
Al pulsar sobre crear mostrará el siguiente formulario:
Al pulsar sobre crear aparecerá un nuevo botón de “Create API” que será el que utilicemos para crear la API:
Al pulsarlo:
Se creará una nueva API:
A continuación se muestra un ejemplo de APi generada:
Release notes - Noviembre 2024 (versión 2.2)
Con APIQuality, podrás desplegar tus APIs en diferentes API Managers de forma sencilla.
Con perfiles de entorno, puedes definir APIOPs para distintos ciclos de vida y definir tus stages según el API Manager en el que quieras desplegar.
A partir de ahora, cuando se suba las colecciones de testing se calculará el % de endpoints que se están probando y un resumen del resultado de la prueba.
La opción de ver el report completo sigue estando activa.
Se ha creado una nueva opción para cancelar el pipeline completo. Sólo tienes que ir a la pantalla de visualización de la API y pulsar sobre el botón de cancelar.
En ocasiones no sabes qué ejemplos se han cargado en Microcks por lo que se ha añadido la posibilidad de poder visualizar directamente en APIQuality los endpoints que tienen ejemplo. Para eso, sólo tienes que pulsar sobre “ver los detalles del mock” dentro de la información de la API:
Esto permite visualizar en qué operaciones no se han cargado los ejemplos y revisar si se está realizando bien el mocking. Si pulsamos sobre una de las operaciones podemos ver mejor la información de la petición cargada:
También podemos ver la información de cada ejemplo si pulsamos sobre ellos.
A partir de ahora, dentro de la pantalla de entornos se podrán crear nuevos perfiles de entorno que permita definir diferentes ciclos de APIOps para cada entorno.
Dentro de la pantalla de entornos se puede ver un nuevo botón que permite crear nuevos perfiles de entorno.
Si pulsamos sobre crear podemos crear un nuevo perfil de entorno:
A partir de ahí, vemos que podemos modificar el mismo entorno (development) pero para cada perfil. Por ejemplo, para las APIs que se desplieguen en Azure no queremos que se haga ni mocking ni contract tests en el entorno de desarrollo. Lo editamos en el entorno y ahora podemos ver que los entornos ya son diferentes para cada perfil:
Después, sólo tendremos que seleccionar el perfil de entorno al crear la api y así seleccionaremos el ciclo de APIOps relacionado:
La nueva versión permite generar un spectral a partir de la guía de estilos desarrollada en openapi. Este espectral estará enlazado al spectral que se guarda en cada repositorio y por tanto se podrá utilizar por cualquier programa de diseño de APIs siendo compatible con las reglas sonar configuradas.
Para poder ver el spectral que se genera se puede ir a la pantalla de guía de estilos: 
Si descargamos el fichero y lo metemos en un repositorio con una api y lo abrimos con Visual Studio Code, si activamos el plugin de spectral y renombramos el fichero a .spectral.yml podemos visualizar cómo las reglas de APIQuality empiezan a validarse en local tal y como se aprecia en la siguiente imagen:
Si visualizamos el repositorio de la API podemos ver que se ha generado automáticamente el fichero de spectral y que simplemente clonado el repositorio y abriéndolo con Visual Studio Code u otro ide de definición se puede utilizar.
Si se ha activado el stage de openapi2postman se ha añadido una configuración avanzada que permite configurar las diferentes opciones que permite la herramienta. A continuación se muestran unas pantallas:
- Custom Oauth2: Permite configurar las peticiones a oauth para obtener los tokens y utilizarlos en el resto de peticiones. Cuando se activa el oauth hay que añadir la url dónde obtendremos el token.
- Cuando se ejecuta, crea una colección con una petición a oauth2 :
- Is inline: Define los datos del cuerpo del request si el valor se recogerá de los entornos o bien se ponen directamente en la petición. Si el valor es:
- True:
- False: los datos se recogen del entorno:
- Schema is inline: Se comprueba el esquema de salida con el que se valida las salidas de la petición.
- true: El esquema para validar la salida se guarda en la configuración de entornos.
- false: El esquema se muestra en postman en la parte de scripts.
- Schema pretty print: Permite mostrar de forma visual el esquema que se utiliza para validar la salida del postman y así poder configurarlo mejor.
- true: Se muestra de la siguiente forma:
- Has scopes: Indica si tiene o no scopes. Si tiene scopes hay que indicar el número de scopes. Si tiene scopes se crea una petición por cada scope tal y como se puede ver en la imagen:
- Application token: Permite probar la aplicación con token de usuario y token de aplicación.
- Microcks headers: Permite testear un mock creado con microcks. A continuación se puede observar en la siguiente imagen como introduce una cabecera con el nombre del ejemplo a devolver.
A continuación se enumeran los bugs resueltos:
- Resuelto el bug que no dejaba al perfil API Designer guardar un comentario.
- Resuelto el bug de redocly que seguía mostrando la información del reporte una vez eliminado el stage del entorno.
- Se ha cambiado el mensaje del límite de usuarios de una organización cuando un usuario intentaba registrarse dentro de la misma. Hasta el momento sólo le mostraba un mensaje de “error”
- Se ha resuelto un bug por el cual no se actualizaba correctamente la url de microcks que se mostraba dentro de una api cuando se creaba una nueva versión de la API.
- Se ha resuelto un bug que no permitía seleccionar el modo de vinculación (Cloud / Server)
Release notes - Octubre 2024 (versión 2.1)
Se ha añadido linter (en este caso, redocly) que permite lintear la API antes de pasar la guía de estilos de la organización.
El linter se activa dentro del ciclo de APIOps del entorno:
A continuación se muestra la información:
Este linter se puede ejecutar dentro del ciclo de vida APIOps
y se puede revisar el resultado dentro del rating global de la API:
Las oportunidades pasan a poder tener dominios y la gestión de permisos se unifica con los mismos.
A partir de ahora las oportunidades se deben especificar dentro de los dominios y los permisos son los mismos que se aplican a las APIs.
Al crear la oportunidad debemos definir en qué dominio le aplica:
Hasta el momento, la documentación que se mostraba era la generada en Microcks. Ahora, la documentación se genera directamente en la propia herramienta.
Tal y como se puede ver, dentro de la pantalla de la API existe una opción de ver documentación:
Esta pantalla permite visualizar la documentación dentro de la propia herramienta.
A la hora de generar nuevos ficheros con todos los enlaces href externos, se puede configurar en 3 sitios:
- A nivel de organización
- Cuando se importa un openapi
- En un Stage
Una vez activados, cuando trabajamos con el fichero con referencias se creará un fichero entregado tanto en json como en yaml, para su uso posterior para otras herramientas.
Actualmente, existen una serie de parámetros que son necesarios para configurar la guía de estilos y que posea una coherencia. Se ha creado un formulario para registrarlos y así crear la guía de estilos acorde con la organización:
YAML Style:
Una de las primeras cosas que se debe definir en una guía de estilos corporativa es el formato de definición de parámetros, cuerpo de entrada y cuerpo de salida.
Las reglas que se van a configurar son las siguientes:
- OAR011 – UrlNamingConvention – The base path and resource names with more than two words must be compliant with the standard naming convention
- OAR066 – SnakeCaseNamingConvention – RequestBody and Responses schema property names must be compliant with the snake_case naming convention
- OAR067 – CamelCaseNamingConvention – RequestBody and Responses schema property names must be compliant with the camelCase naming convention
- OAR068 – PascalCaseNamingConvention – RequestBody and Responses schema property names must be compliant with the PascalCase naming convention
Headers request:
En esta sección se indican qué cabeceras son permitidas en la definición y cuales son las obligatorias. Se pueden excluir algunos paths de esta validación. La regla que se va a configurar es la siguiente:
- OAR033 – HttpHeaders – There are mandatory request headers and others that are not allowed
Format responses:
El importante tener una definición de objeto única para todas las apis y es un parámetro a introducir en la validación en la guía de estilos. El formato se añade en formato json. La regla que se va a configurar es la siguiente:
- OAR029 – StandardResponse – Response schema must be compliant with the standard
Paging
La paginación es importante en cada organización y se debe definir los parámetros a introducir dentro de la organización.
Status
Normalmente el /status es un endpoint de health que se pone en las apis y es bueno indicarlo dentro de la definición
- OAR030 – StatusEndpoint – Status endpoint must be declared
href
En las guías de estilo más avanzadas no sólo se valida el formato sino como se crean los openapi. Esta opción permite validar que los ejemplos, componentes, esquemas se definen en la sección de componentes.
- OAR088 – RefParam – The $ref of a parameter must end with a corresponding suffix
- OAR089 – RefRequestBody – The $ref of a request body must end with a corresponding suffix
- OAR090 – RefResponse – The $ref of a response must end with a corresponding suffix
- OAR091 – ParamOnlyRef – Parameters must contain only references ($ref)
- OAR092 – RequestBodyOnlyRef – RequestBody must contain only references ($ref)
- OAR093 – ResponseOnlyRef – Responses must contain only references ($ref)
Parametros especiales
Es buena pragsis añadir parámetros especialices para flexibilizar la api como $select, $expand.. pero no todas las compañías lo tienen. Con este check permite habilitarlos todos de forma conjunta. Se habilitan las siguientes reglas:
- OAR019 – SelectParameter – the chosen parameter must be defined in this operation
- OAR020 – ExpandParameter – the chosen parameter must be defined in this operation
- OAR021 – ExcludeParameter – the chosen parameter must be defined in this operation
- OAR022 – OrderbyParameter – the chosen parameter must be defined in this operation
- OAR023 – TotalParameter – the chosen parameter must be defined in this operation
- OAR024 – StartParameter – the chosen parameter must be defined in this operation
- OAR025 – LimitParameter – the chosen parameter must be defined in this operation
- OAR028 – FilterParameter – the chosen parameter must be defined in this operation
Se ha añadido una nueva opción en el settings de organización que permite securizar las llamadas del mock a través de un apikey.
Se añade una opción que permite securizar la llamada a los endpoints del mock de microcks.
Se han empezado a permitir stages bloqueantes. Por el momento, sólo está disponible para la guía de estilos sonar. Para poder definir una letra mínima, se debe configurar dentro del ciclo de apiops dentro del entorno y seleccionar la letra mínima:
Se añade un checkbox a nivel de organización para poder activar o desactivar que se añada el server de mocking automáticamente:
Si configuramos esta opción se generarán todos los openapi con un nuevo server con la url de microcks
Se ha habilitado la opción de poder desplegar en Wso2 configurando el api.yaml para la versión Wso2.
Una vez habilitado el stage, dentro del propio stage podemos configurar este fichero.
A continuación se muestra el fichero api.yaml para el entorno.
Si desplegamos la API se puede ver en Wso2.
Eliminar las credenciales de sonar del repositorio
Por seguridad, se eliminan las credenciales de sonar del fichero sonar.properties
- Se resuelve un bug por el cual se duplicaban las reglas de sonar al crear una nueva guía de estilos.
- Se resuelve un bug que generaba fallos al actualizar una api desde el editor.
- Se modifica para que se muestre el scoring de test.
- Se resuelve un bug por el cual se visualizaba un error en las fechas, a la hora de subir una nueva API o modificando una ya existente. La update ya no se muestra vacía.
- Se resuelve un bug por el cual se mostraba la fecha de creación y de modificación a fecha de 16 de febrero de 2023.
- Se resuelve un bug por el cual se mostraban dos “undefined” en los mensajes de commit. También se resuelve que quede registrado quién ha lanzado la ejecución.
- Se resuelve un bug que permitía crear ramas con tilde en el nombre.
- Se resuelve un bug que no permitía eliminar una rama local.
- Se resuelve un bug que no permitía eliminar las ramas globales.
- Se resuelve un bug por el cual no se generaba la carpeta resolved.
Release notes - Agosto 2024 (versión 2.0)
En la nueva versión se puede obtener información directamente de la ejecución de los stages del CI/CD. Esta opción estará disponible pulsando sobre el icono (aspa o ok) disponible en cada stage.
A continuación se muestra la información:
A partir de ahora, existe una nueva opción para mostrar el histórico de ejecuciones del CI/CD directamente desde APIQuality. Esta opción estará disponible en el menú contextual disponible en la ejecución.
A partir de ahora se podrá cambiar tanto el nombre de la api como el nombre del fichero del repositorio directamente desde la interfaz. Sólo habrá que pulsar sobre editar en la pantalla de visualización de una API:
Y se cambiará automáticamente en el repositorio
Las entornos (ramas) que se creen a nivel de organización estarán disponibles para todas las APIs, pudiendo definir ramas personales en cada API.
Sólo los administradores y api architect podrán definir ramas para todas las apis.
Para openapi que utilicen ficheros externos, se ha creado una nueva funcionalidad que permite generar el openapi con las referencias externas. Esta funcionalidad puede ser configurada por el administrador de organización en settings.
o bien puede hacerse sólo sobre el fichero que estamos importando:
o bien se puede crear como un stage más:
Se ha añadido el nombre del usuario en los commits para que se pueda visualizar quién ha realizado los cambios. Hasta el momento era el usuario genérico de APIQuality el que se mostraba sin especificar quién era el usuario de APIQuality.
Para las licencias enterprise se ha habilitado un nuevo frontal dónde pueden realizar login con SAML y así conectar su login corporativo.
A continuación se muestra un listado de pequeñas mejoras:
- Ordenar el campo de dominios al subir una nueva API
- Se le ha dado permisos al api design para poder ver los modelos.
A continuación se muestra un listado de bugs en la versión:
- Se modifica para que no muestre como editor el creador de la api.
- Se resuelve un bug por el cual al crear una nueva rama podía coger el nombre del fichero antiguo que se había eliminado previamente.
Preguntas frecuentes
¿Tienes alguna duda sobre cómo funciona APIQuality? Estas son las preguntas más frecuentes (FAQs) que nos hacen nuestros clientes.
APIQuality es una plataforma que facilita el desarrollo, prueba y despliegue de APIs. Está diseñada para ayudarte a implementar la metodología API-First de manera eficiente y automatizada. Básicamente, hace que trabajar con APIs sea mucho más sencillo y seguro.
Con APIQuality, puedes:
- Crear prototipos automáticamente: Generamos modelos de tus APIs a partir de definiciones.
- Realizar pruebas continuas: Ejecutamos pruebas automáticas para asegurarnos de que tus APIs funcionan correctamente.
- Generar datos de prueba: Creamos datos ficticios para probar tus APIs en diferentes escenarios.
- Simular errores: Probamos cómo responden tus APIs ante fallos para mejorar su robustez.
- Desplegar y monitorear: Gestionamos tus APIs y supervisamos su rendimiento en tiempo real.
Usar APIQuality te ofrece múltiples ventajas:
- Automatización: Reducimos el trabajo manual en el desarrollo y prueba de APIs.
- Seguridad: Detectamos y solucionamos vulnerabilidades automáticamente.
- Integración: Funcionamos con herramientas populares como Gitlab y Postman.
- Flexibilidad: Somos compatibles con tecnologías como C# .net y Java Springboot
En APIQuality tenemos varios planes según tus necesidades:
- Free Plan: Gratis, permite gestionar hasta 5 APIs.
- Business: desde 49€ al mes, para gestionar hasta 30 APIs.
- Enterprise: precio a consultar, sin límite en el número de APIs.
- Dev Portal: precio y condiciones a consultar.
Cada plan está diseñado para ajustarse a diferentes niveles de uso y necesidades empresariales.
En APIQuality realizamos escaneos de seguridad en tiempo real para detectar y solucionar vulnerabilidades. Además, proporciona estadísticas detalladas y te ayuda a definir estándares de seguridad para tus APIs, asegurando que cumplan con las mejores prácticas del sector.
Para ofrecerte lo mejor, en APIQuality integramos varias herramientas open-source como:
- OpenAPI2Postman: Para generar pruebas y validaciones.
- doSonarAPI: Para validar definiciones de APIs según estándares corporativos.
- API Generator: Para crear arquetipos de microservicios conectados a bases de datos.
Si necesitas ayuda, puedes contactar con nuestro equipo de soporte de APIQuality enviando un correo a [email protected] o llamando al +34 917 64 79 82. También puedes usar el formulario de contacto en su sitio web para cualquier consulta.
En las versiones híbridas se puede utilizar sonarlint para poder probar directamente en local.
Si pones en el comentario el nombre de los stages, se ejecutarán en APIQquality los stages configurados.
Sí, se puede crear un custom stage que utilice las operaciones que tengas dentro de tu CI/CD.
En este caso la versión híbrida utiliza una vpn para poder conectarse a las piezas que estén en local. Para la versión híbrida sólo se puede utilizar en la licencia enterprise.
No, pero pronto tendremos una versión que permitirá cambiar el orden.
Actualmente se puede utilizar GitlabCI y Bibucket y se está trabajando en Github y AzureDevops. Si utilizas otro sistema, se puede utilizar fácilmente utilizando webhooks desde tu sistema de CI/CD al GitlabCI.
Debes entender que el sistema que se utiliza es APIOps, lo que significa que los procesos se ejecutan en el CI/CD y en ocasiones puede tardar un poco en asignarle un job de ejecución.
Actualmente sólo existen dos versiones, SaaS y versión Hybrid. Si tienes otras necesidades, no dudes en proponerlo al equipo de producto.
En este caso, debes hablar con el equipo de gobierno de APIs o las personas encargadas de definir la guía de estilos, para saber si tienen algún error de parametrización.
Sí, pero Microcks viene por defecto dentro de la herramienta.
En la versión SaaS no es posible, pero puedes desarrollar diferentes configuraciones directamente dentro del openapi, según las extensiones del openapi.
En la versión SaaS no es posible, sólo se puede hacer en la versión hybrid.
Por el momento, soporta mulesoft, wso2 3.2, Wso2 4.1, Kong 2.X, Azure API Management, Apigee X, AWS API Gateway.
APIQuality está ofreciendo API Rating tanto de definición, calidad, mocking y seguridad basada en definición. Se está trabajando para añadir nuestras métricas.
El concepto de APIOPs que viene por defecto es en GitlabCI en el SaaS. Pero eso no quiere decir que no puedas conectar tu propio sistema de integración continua CI/CD.
No por el momento.
Para la generación de microservicios utilizamos APIgen ASP.NET y APIgen Java Springboot, ¿de dónde salen estos generadores?
Estos generadores los han desarrollado diferentes empresas bajo el paraguas de la fundación APIAddicts. Puedes ver los proyectos en:
APIQuality: plataforma de APIOps para empresas
Ahorra un 70% de tiempo y crea mejores productos
Aumenta la productividad de tu equipo en un 82%
Multiplica el consumo y uso de tus APIs
APIQuality: innovación y apoyo a tu alcance
Tu éxito con APIs comienza aquí. En APIQuality, combinamos tecnología avanzada, soporte dedicado y una comunidad activa para ayudarte a transformar tus procesos y alcanzar tus objetivos más rápido.
¿Listo para llevar tu gestión de APIs al siguiente nivel?