API First sin Cloud: Cómo construir APIs robustas con bajo costo
El desafío de construir APIs es terreno del desarrollo backend y arquitectura de integración, pero que afecta también a los posibles consumidores, ya sea un frontend web, una app para dispositivos móviles u otro tipo de cliente final del API o las APIs, incluso en ciclos de desarrollo más estrictos, a los equipos QA que realizan pruebas de API, ya sea de forma manual o automatizada.
Para abordar este desafío, los equipos y los roles involucrados suelen aplicar procedimientos y métodos para poder definir y diseñar una API. Existen diferentes tipos o estándares de construir APIs; entre los más comunes se encuentran REST, GraphQL, gRPC, SOAP, OData, entre otros. Cada uno con sus formas, convenciones y protocolos para la definición de un API. En este artículo voy a centrarme en REST, que es, si no, el estilo de arquitectura más adoptado actualmente para construir APIs.
En cuanto a REST, hay ya todo un conjunto de procedimientos bastante conocidos para definir un API, ya sea que uses un estilo flexible o uno más estricto como RESTful. Desde las convenciones de nomenclatura, definición de URIs base y URIs dinámicas, definición de métodos HTTP, definición de parámetros en queryString, parámetros en el cuerpo de la petición y definición de resultados y errores.
API First es uno de los enfoques de construcción y diseño de APIs que se promueven en la actualidad. Básicamente, consiste en definir la especificación de las APIs REST antes mencionadas y los contratos antes de codificar la lógica de negocio. Esta primera definición lograda permite que los consumidores puedan avanzar en paralelo en base a esa definición y puedan apalancarse de técnicas como mocking y stubs.
En REST, esta primera definición puede lograrse siguiendo el estándar OpenAPI, o anteriormente llamado Swagger; para gRPC, esto puede lograrse definiendo los Protobuf primero. Para seguir el estándar OpenAPI, muchos equipos se apalancan de servicios SaaS especializados como API Hub/Swagger Hub, y muchas plataformas cloud cuentan con servicios tipo PaaS, por ejemplo, Azure API Management de Azure.
Es cierto que estas plataformas son geniales y facilitan enormemente el trabajo con todos sus componentes y ecosistema, pero, ¿qué pasa si no me puedo permitir usar estas plataformas? Este es un escenario muy real de muchos equipos, ya sea porque no cuentan con el presupuesto, o porque tienen requerimientos empresariales de aplicaciones y sistemas no cloud.
¿Cómo se puede hacer API First con bajo presupuesto y sin Cloud?
Desde mi experiencia te dejo las siguientes recomendaciones:
- Apalancarse de librerías que sirven para implementar OpenAPI desde el código. Este enfoque consiste en codificar los endpoints o métodos de controlador primero, definiendo tipos de entrada y de respuesta, así como parámetros y errores que se pueden producir sin programar la lógica de negocio. Sobre este código, integrar librerías como Microsoft.AspNetCore.OpenApi de .NET o el clásico Swashbuckle.AspNetCore, que te permiten generar la documentación OpenAPI a partir del código. El resultado puedes compartirlo con tu equipo de fronts y QAs para que puedan continuar con sus actividades. Opcionalmente, y si deseas, estas librerías también pueden brindarte una UI para que puedas ver la documentación de forma amigable. Aquí puedes optar por Swashbuckle o Scalar.
- Para implementar mocking y stubs, tus equipos pueden instalar localmente MockServer, que, a partir de tu definición, puede montar un server API como si fuera una API real y simular respuestas.
- Si prefieres ser purista y no te parece hacer código para lograr OpenAPI, tienes opciones como NSwag de .NET. Esta librería te permite hacer las definiciones con JSON o YAML, y a partir de esta definición generar código como controllers y clientes.
- Con estos inputs tus equipos de desarrollo mobile o frontend pueden generar sus tipos de request/response asi como los clientes para consumir las APIs, con lenguajes como TypeScript y librerías como Axios o un ecosistema nativo como Android o iOS.
Pongo como ejemplo .NET por ser mi ecosistema favorito, pero esta misma figura puede aplicarse a ecosistemas como Java con Spring Boot y Python con FastAPI, ya que cuentan con librerías que sirven para implementar OpenAPI.
Por otro lado, si deseas una alternativa cloud, pero de bajo costo, una opción es implementar Azure API Management en su Developer Tier, donde puedes escribir/subir las definiciones de API para publicar APIs simuladas y tus equipos puedan hacer mocks.
La siguiente imagen puede darte una idea para implementar API first en tus equipos.
Conclusiones
- API First es un gran enfoque para construir tus APIs de una manera más eficiente de cara a los diferentes roles del equipo de desarrollo. Las plataformas existentes para hacer OpenAPI son geniales, pero existen formas y hay ecosistema para poder lograr esto con bajo costo y una pequeña curva de aprendizaje.
- Con API first la definición anticipada de contratos permite ahondar en la lógica de negocio a todo el equipo de desarrollo de la mano con los expertos en el negocio.
Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades