Desde hace un tiempo estoy retomando el desarrollo de proyectos de integración y he vuelto a retomar conceptos referentes a APIs que me gustaría compartir. Espero que ayude a quien tenga curiosidad o dudas respecto a este tema.
- ¿Qué es una API? Es una aplicación de tipo backend que usualmente sirve como intermediario entre la comunicación de sistemas o componentes. Es agnóstico al lenguaje de los sistemas que lo invocan, por lo que tiene apertura a ser ejecutado desde diferentes canales.
Piensa que es una pieza que sirve de engranaje maestro para que dos o más sistemas se comuniquen. Suele ser muy sensible a cualquier tipo de cambios, ya que puede ocasionar impactos colaterales. Con el fin de mitigar estos problemas se desarrolló la especificación llamada Swagger.
¿Para qué sirve Swagger?
Es la definición que explica el funcionamiento y las capacidades que tiene una API. Como a los desarrolladores les gusta estructurar todo y poder ver la información de un vistazo. Se utiliza un formato de texto que explique de forma rápida e intuitiva las capacidades que tiene este programa. Responde a preguntas, ¿para qué me sirve?, ¿cómo debo ejecutarlo? y ¿qué debo esperar como respuesta?. El formato del Swagger puede ser YAML o JSON.
- ¿Ahora qué demonios es OpenAPI?
Durante el 2015, Swagger fue muy popular entre el mundillo y por una obra de altruismo se donó a la organización OpenAPI (No OpenAI) que quería estandarizar esta especificación en toda la industria. La última versión de Swagger fue 2.0 por lo que a partir de entonces también se le conoce como OpenAPI 2.0. Actualmente hay versiones más recientes que se llaman únicamente OpenAPI.
- Tipos de APIs
Como el usuario es muy demandante y los desarrolladores gustamos de satisfacerlos, hay un catálogo de tipos de APIs específicas para diferentes necesidades.
- HTTP API: Usualmente los primeros que se aprenden a programar. Ya sea por su simplicidad en la integración entre sistemas o porque es capaz de cubrir una gran cantidad de necesidades.
- Async API: Se empieza a complicar. No suele ser una única pieza como la anterior, necesita de otras herramientas para funcionar, por lo que la pieza intermedia se convierte en un conjunto de piezas para ejecuciones asíncronas.
- GraphQL API: Para consumo de datos donde el cliente decide los datos que necesita. Entra otro concepto importante, los websockets.
- gRPC API: Envío de datos comprimidos para entornos donde cada byte cuenta. Muy útil para IOT.
¿Por dónde empezar?
Nada tan gratificante como responder una pregunta con Depende. El contexto de lo que quieres programar es importante, también el alcance de usuarios o invocaciones que tendrá la pieza. No es lo mismo construir una API tú solo y que se invoque 1 vez al día, a tener un equipo de 5-10 personas con una expectativa de uso de 1000 peticiones por minuto.
Para responder la pregunta podemos guiarnos de las siguientes formas de trabajo:
- Code First: Programar lo que quieras para luego, a partir del código, crear la especificación OpenAPI, el contrato.
- Contract First: Programar la API a partir de un contrato establecido. Hasta que no se termine la especificación de la API no se escribe ninguna línea de código, si el contrato cambia se ajusta y comparte con el resto de sistemas.
- API First: Es una metodología con lineamientos de cómo construir el contrato en base a necesidades, objetivos y alcance. Es como dedicar tiempo preliminar antes de empezar a construir la especificación para que cumpla una serie de buenas prácticas.
Espero os sirva.
Top comments (0)