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 - 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.
Aprende más sobre APIQuality
Preguntas frecuentes
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 contacta@apiquality.io 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:
¿Por qué escoger APIQuality?
El integrador de API Tools que beneficiará significativamente a tu empresa y tu equipo técnico.
Beneficios de negocio
Ahorra tiempo en hasta un 70% mientras creas mejores productos
Refuerza la seguridad de tu negocio
Aumenta la productividad de tu equipo en un 82%
Impulsa el consumo y uso de tus APIs
Acelera la entrega de proyectos
Beneficios técnicos
Unifica todo tu ciclo de API First en una única herramienta
Controla y soluciona los bugs y vulnerabilidades
Automatiza tus tests
Genera mocks para agilizar tus procesos internos de desarrollo
Monitorea tus APIs en tiempo real
¡Prueba ya APIQuality!
Regístrate y pon a prueba tus APIs, sin compromiso ni tarjeta de crédito