🚀 Nuevas funcionalidades

¿Qué és una API?

Tenía que escribir este post. Está totalmente dirigido a gente que no tiene un perfil técnico. Gente a la cuál me gustaría hacerle un TAC y saber lo que se enciende en su cerebro. No dejo de preguntarme que imaginan cuando oyen API.

API = application programming interface

Son las típicas siglas que llenan de humo las reuniones de marketing y demás. Qué es una API exactamente? Muy buena pregunta.

Podemos reconocer una API por la siguiente estructura o componentes:

  • Documentación que explica como usarla (más adelante explico que quiere decir usarla)
  • Unos endpoints o urls, que aparecen también el documentación
  • Un formato, o varios, para intercambiar datos.

Una API siempre va acompañada de documentación, ya que el principal objetivo de una API es que personas ajenas puedan usar un sistema de forma segura y controlada. Los docs de una API siempre explican como autenticar nuestras llamadas, que tipo de acciones podemos realizar, que información debe acompañar a cada acción, y que tipo de información será devuelta con cada llamada.

Es curioso, porque una API es muy sencilla. Pero explicar que es una API no es tan fácil.

Visitar un sitio web sería una «llamada». Ahora imagínate que es un programa el que hace esta llamada y sin navegador. Creo que esta frase puede ser la más útil para entender cómo funciona una API.

Empecemos con los ejemplos. Tenemos una cafetera. Alguien ha desarrollado una API sobre esta cafetera.

La api de la cafetera viene acompañada con la siguiente documentación:

  • cafetera.com/api/encender.  (No hace falta mandar ningún parámetro)
  • cafetera.com/api/apagar. (No hace falta mandar ningún parámetro)
  • cafetera.com/api/cafe (Hay que mandar el parámetro «tipo» con valor «corto» o «largo», para definir el tipo de café que queremos)

Ya tenemos los endpoints o urls de la API de la cafetera. Faltaria saber que información necesita cada endpoint, que respuesta devolverá y todo esto, con qué formato debe realizarse. Por formato me refiero a JSon/XML/CSV/… cualquier estándar de datos estructurados. Cada API usará un formato tanto para las respuestas, como para recibir argumentos o parametros de cada llamada.

Imaginemos que nuestra API usa JSON, tanto para las respuestas como las llamadas. Json es un formato reconocible por ser algo como:
{ «estado»: 0, «error» : false, «fecha»: «30/10/2018» }. Esto es lo que se conoce popularmente como un string JSON. Es simplemente una estructura de campo => valor. Poco legible para humanos quizá, pero genial para que dos procesos computacionales intercambien datos por internet.

Con hacer una llamada a los endpoints de encender o apagar ya podemos saber lo que pasará. No se necesita mandar ningún parámetro extra. Con hacer una llamada a esa URL (lo que seria visitar una página con nuestro navegador) ya se ejecuta la acción.

Vamos por tanto con el último endpoint que se utilizaría para «ejecutar» un café, recogiendo el parámetro tipo, que ayudará a la máquina a saber que tipo de café tiene que ejecutar.

Lo típico es que si no mandamos el parámetro tipo, nos devuelva una respuesta con el error. En caso de que el valor de tipo también sea incorrecto o desconocido también devolvería error.

Si lo hacemos todo correcto, el proceso sería asi:

ordenador A: Hace llamada a /api/encender, cuando la respuesta nos dice que la cafetera, está encendida podemos llamar seguidamente a /api/cafe?tipo=corto
API: Respondería por ejemplo con: { «error»: false, «ready» : true }, gracias a la documentación sabemos que si devuelve ready: true, es que el café se ha hecho correctamente y está esperándonos en la cafetera.

Quizá el ejemplo de la cafetera no es el mejor, y podría desarrollar mucho más las llamadas y respuestas, pero no tengo claro si eso sería ampliar la información o crear más dudas….

Si te ha servidor, comenta o comparte. Gracias!

 

Beto López
Programador de páginas web "full stack" especializado en el mantenimiento y corrección de errores de Wordpress, Prestashop, HTML, CSS, Javascript, Php y Mysql. También colaborador de proyectos open source. Linkedin  contacto@phpninja.info twitter @betoayesa.
¡Ayuda! ¡Errores en mi web!
Reparación Web. Arreglamos cualquier cosa que necesites. Por favor introduce la dirección de la página web a arreglar.

Hecho!

Revisaremos tu página web y nos pondremos en contacto rápidamente

Ha ocurrido un problema, por favor inténtalo de nuevo

Por favor, vuelva a intentarlo



Nosotros lo arreglamos, puedes estar tranquilo
No importa el problema, no importa el código, estamos aquí para ayudarte.


¿Alguna duda? Contacto
by Beto