Cuando realiza una búsqueda en la web de "cómo crear una API", descubrí que aparecen bastantes opciones, pero muy pocas son guías completas. Esto puede deberse a mis escasas capacidades de búsqueda web o porque es bastante difícil crear una API (llevarla desde el diseño hasta la producción).
Cualquiera que trabaje con API le dirá que puede ser toda una proeza y que, por lo general, lo gestiona un equipo de personas. Por lo tanto, crear una API usted mismo y ponerla en producción para que sus usuarios puedan comenzar a usarla puede ser un desafío importante.
Vivimos en una época afortunada donde existen multitud de herramientas que hacen mucho más llevadera esta tarea. Con algo como Postman, podemos crear la especificación API, probar la especificación API y, en última instancia, probar nuestra API para asegurarnos de que funciona como se espera. Para construir el back-end de nuestra API, necesitaremos una gran cantidad de herramientas como Flask, Heroku y más, o podemos optar por una herramienta de código bajo para construir y alojar nuestra API.
En esta publicación, veremos el proceso de creación de una API y cómo se puede hacer que este proceso sea más eficiente.
Proceso de desarrollo de API
El desarrollo de API es complejo, no hay forma de evitarlo. Por lo general, necesitamos diseñar la API, codificar, probar, depurar, codificar nuevamente, probar un poco más, implementar cuando estemos listos y luego está el mantenimiento aparentemente interminable. Un ciclo de vida de desarrollo de API típico se verá así:
Normalmente, cada paso del proceso lo realizará otra herramienta o recurso, por lo que implementar una API puede convertirse en un gran esfuerzo.
Por ejemplo, podríamos optar por usar Postman para diseñar nuestra API (Especificación de API abierta) y usar algo como un matraz para nuestro código, conecte firebase o alguna base de datos para almacenar o recuperar nuestros datos. También es posible que necesitemos realizar llamadas REST adicionales a otras API y servicios. Para probar, podemos usar Postman nuevamente, pero depurar el código y todos nuestros conectores puede volverse problemático. Para la implementación, podemos optar por Heroku, pero depende de lo que requiera nuestra API. Para monitorear, podemos crear nuestro sistema de monitoreo o usar algo como Splunk. Y cuando necesitamos mantener nuestra API, debemos volver a sumergirnos en todo eso. Entiendes lo que estoy tratando de decir. El desarrollo de API es complicado.
Encontrar una mejor manera
Quería una manera de simplificar el ciclo de vida de desarrollo de API y desarrollar mis API desde el diseño hasta la producción con solo unas pocas herramientas. Gracias a herramientas low-code como Linx, esto es posible. Pude crear una API, desde el diseño hasta la implementación, usando solo tres herramientas:
- Cartero Usé cartero para crear mi especificación API (basada en YAML) y para probar mi API
- Linx que usé
Linx para construir mi API, implementar la lógica, depurarla y finalmente alojarla. Nota rápida, también puede intentar crear una API con este tutorial guiado. - SQL Server SQL Server se usó para almacenar datos para mi API. Usé la base de datos AdventureWorks2019 creada previamente y sus datos.
El requerimiento
Opté por una API sencilla que hará el mantenimiento de los registros de usuario. La API tiene cinco métodos:
Crear la especificación
Creé una especificación de API sencilla en Postman usando YAML que cumple con el requisito. Postman me permitió ver lo que creé y proporcionó visualmente información adicional. La creación de la definición de API en Postman también beneficia, ya que configura esa API para la prueba. Si lo desea, puede configurar los scripts de prueba en esta etapa.
Construyendo la API
Ahora que tengo la definición de API, se puede crear el código. Linx le permite importar una especificación OpenAPI 3.0 y generará automáticamente los eventos para cada método especificado. Solo necesitaba especificar el URI y luego construir la lógica.
La creación de la lógica de cada evento es relativamente rápida una vez que se instala el complemento de la base de datos. Linx tiene una curva de aprendizaje como todas las herramientas, pero una vez que entiendes cómo trabajar con ella, el ritmo se acelera.
Agregué lógica y funcionalidad a cada evento para la API. Por ejemplo, para el método GetAllUsers, todos necesitábamos leer de la base de datos SQL y devolver los resultados a través del cuerpo de la respuesta.
Probando la API
Debido a que la API ya está configurada en Postman, fue bastante fácil probar, en tiempo real, cómo funciona la API ahora que se implementó la lógica. El siguiente GIF muestra cómo utilicé el diseñador Linx para depurar la API REST que creé y cómo la estoy probando en modo de depuración.
GIF
Con la API depurada en Linx, está alojada para que pueda llamarla y ver cómo se comportará cuando la implemente. Esto me permite probar y obtener un resultado real:
Por supuesto, también podemos agregar scripts de prueba en Postman para automatizar nuestro proceso de prueba. Estos scripts garantizarán que obtenga la respuesta correcta.
Implementación de la API
Ahora que la API ha sido diseñada, desarrollada y probada, debe implementarse. Esta puede ser una tarea sustancial con el desarrollo de API tradicional, ya que necesitamos idear una estrategia de implementación, averiguar dónde alojaremos qué y asegurarnos de que se cuiden la supervisión y el registro y más.
Mi despliegue fue bastante simple. Implementé la API de Linx Designer directamente en Linx Server. La solución tardó aproximadamente 2 minutos en compilarse, enviarse al servidor y estar lista para usar. La dificultad de alojar una API se elimina ya que el servidor Linx se encarga de esto. También hace monitoreo y registro:
Llamé al método GetUser con una ID incorrecta para ver qué sucedería si ocurriera un error inesperado. El servidor registra el error e indica con rojo que ocurrió un error:
Pude volver a llamar a la API desde Postman, y el servidor da una indicación cada vez que se llama a la API.
Es cierto que no agregué ninguna forma de seguridad o autenticación a mi API, pero estas configuraciones están disponibles en el diseñador de Linx. Otra opción que probé fue generar la Documentación API en formato swagger. Esto resultó ser bastante valioso porque al agregar /swagger al URI base, la documentación está disponible y alojada con la propia API. Esto facilita la distribución de la documentación de la API cuando sea necesario.
Terminando
Al combinar Linx y Postman, podemos diseñar, crear, documentar y alojar API. Se necesita un poco de tiempo para acostumbrarse, como cualquier herramienta. Debido a que Linx usa paradigmas y jerga de programación estándar, es fácil de aprender si está familiarizado con un lenguaje de programación como C#. Siento que ahorramos la mayor parte del tiempo cuando implementamos y alojamos una API con Linx. El monitoreo y el alojamiento se realizan por usted, lo que significa que se soluciona un dolor de cabeza sustancial. Si el registro y la supervisión no son lo suficientemente granulares, puede agregar su funcionalidad a la solución Linx.
Si desea intentar crear una API con Linx, puede intentarlo usted mismo
- usando
diseñar primero (con cartero) o código primero (solo construye)
También publicado aquí .
