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 - 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 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:
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?