API es uno de los primeros conceptos al que nos enfrentamos los que nos estamos iniciando en el mundo de la computación. Si vamos directo al navegador a buscar en google “What is an api?”, “API”, “What is an api in simple terms” nos encontramos con mucha información, miles de explicaciones diferentes y al leer las definiciones llega a ser un poco abrumador y puede resultar difícil sentirnos cómodos con un concepto que parece un poco abstracto. Un ejemplo clásico para entender qué es una API es el de las mesas y la cocina:
Esto nos deja clara una cosa, la API está encargada de comunicar a alguien que necesita algo (las personas que quieren comida) con quien está encargado de producir lo que ellos esperan (el staff de la cocina).
No sé ustedes pero creo que con eso no nos alcanza para aclarar bien el concepto y radiantemente decir "Ya me manejo con las APIs". Después de todo, no es tan distinto a las definiciones más "formales" que podemos encontrar.
API es un acrónimo para Application Programming Interface ...
-Application programming: Es la parte de “programar alguna aplicación”.
-Interface: ¿Qué es una interfaz?, la interfaz más común que puede que hayas escuchado es la “Interfaz de usuario”; estas son un medio que nos permiten comunicarnos con dispositivos de forma simple, sin necesariamente comprender la complejidad que pueda existir por detrás.
Pasemos ese concepto a la programación, entonces una API es una interfaz, que nos permite comunicarnos con otro programa para escribir nuestras aplicaciones, sin necesidad de entender la complejidad interna de este programa.
Bueno, ya definimos APIs, y quizás siga “borroso” el concepto!, entonces tratemos de entender desde un poco antes, desde nuestro dolor… ¿Cómo sería el mundo sin APIs?
¿Por qué necesitamos APIs?
Supongamos que vivimos en un mundo sin APIs, y estamos construyendo una app de criminales, donde se pueden encontrar todos aquellos más buscados en distintos países.
Desafío: Obtener la información de los criminales buscados por diferentes organismos internacionales
Problema: Como vemos en la historia si no tenemos APIs, entonces no tendríamos forma de acceder a su info, una forma quizás sería conseguir la lista de otra manera, ya sea ingresando a la página web del FBI (Que puede cambiar mucho) o pidiéndoles que manden por algún medio periódicamente sus datos (Imagínense lo terrible de esto).
Aquí es donde entran las APIs: El FBI reconoce que necesita que sus datos sean más accesibles, para que nosotros o cualquiera que quiera escribir una aplicación que los ayude a difundir la información, pueda hacerlo. Entonces el FBI decide exponer una API, de esta forma ellos proveen una interfaz, con la que los desarrolladores puedan programar sus aplicaciones.
Entonces… ¿Cómo funciona?En este caso, el FBI crea una API y dispone la siguiente documentación www.fbi.gov/wanted/api, con estas instrucciones codeamos en nuestro programa que haga una petición a https://api.fbi.gov/wanted/v1/list, donde esta la lista de criminales.
¿Ves que la url de la API del FBI parte con HTTP?, esta es la forma en la que nos pusimos de acuerdo para enviar mensajes a través de internet, esto es lo más común ya que nos permite obtener datos y funcionalidades que no están en el dispositivo donde está corriendo nuestro programa, sino que se encuentran en otras máquinas, en otra parte del mundo.
Las APIs HTTP también introducen los Métodos HTTP, básicamente podemos enviar distintos tipos de mensaje, por ejemplo si queremos conseguir información vamos a enviar una petición del tipo GET, si queremos crear algo vamos a enviar un mensaje del tipo POST, y si queremos eliminar algo vamos a enviar un mensaje del tipo DELETE.
Dato! El concepto de API, sin embargo, no se refiere exclusivamente a HTTP y pedir cosas a través de internet, también pueden existir APIs, que no se consultan a través de la red, por ejemplo, puedes instalar el lenguaje de programación Ruby en tu computador, y utilizar la API de ruby para programar tus aplicaciones.
SOAP, REST, RESTFUL...? AH??
Como hemos visto, las APIs permiten una especie interacción entre infraestructuras, hemos hablado de por qué existen, y de qué se tratan, pero hay un gran detalle:
¿Cómo nos comunicamos para poder entender qué es lo que queremos pedir y qué es lo que nos quieren entregar?
Sabemos que tenemos que enviarle un mensaje al FBI, y que el FBI define la forma que deben tener estos mensajes, pero ¿qué pasa si queremos ahora consultar la información de la policía de Canadá, o del Reino Unido?, ¿cada uno “hace lo que quiere” y define que los mensajes que ellos requieren son completamente distintos entre sí?, bueno en la práctica esto sería muy negativo dado que se escriben miles de programas y hay miles de APIs, si todas funcionan distinto, tenemos que interactuar de formas distintas con todas ellas, entonces integrar un programa con una API requiere una gran cantidad de trabajo ya que debemos ponernos a estudiar para entender cómo debemos consultar esa API en particular.
Entonces hay que ponerse de acuerdo! Esto es particularmente importante cuando pensamos que, en general, no solamente le vamos a pedir a las APIs que nos den información, sino que las interacciones pueden ser mucho más interesantes, podemos pedirle a las API que creen o eliminen registros, o que actualicen cierto tipo de información.
Es por esto que se han llevado a cabo varios intentos para estandarizar la forma en la que nos comunicamos con API:
SOAP (Protocolo de Acceso a Objetos Simples): durante muchos años fue la forma de estandarizar la comunicación a través de solicitudes HTTP, en formato XML. En estas APIs interactuamos con ellas enviando y recibiendo los mensajes en formato XML.
Entonces para nuestra app de criminales la petición enviada para obtener los detalles de un criminal sería algo así:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getCriminalDetails xmlns="http://criminals.fakefbi.com/wanted">
<criminalId>33</criminalId>
</getCriminalDetails>
</soap:Body>
</soap:Envelope>
APIs JSON: Con el paso del tiempo ganaron popularidad, estas también envían datos a través del protocolo HTTP, pero ya no en formato XML sino que en formato JSON.
En este caso el ejemplo es más simple, ya que para obtener los detalles del criminal con id 33 debemos hacer un request de tipo GET a la url, que sería algo como:
http://criminals.fakefbi.com/wanted/33
Con lo que recibiremos una respuesta en formato JSON:
{
data: {
name: “Lord Voldemort”,
id: 33,
description: “El innombrable”,
}
}
API REST: Se traduce como Transferencia de Estado Representacional (REST o RESTFUL), es una forma de estandarizar pero define la arquitectura de la API.Básicamente lo que hacemos es no solo ponernos de acuerdo en el formato que tienen los datos en los mensajes enviados (por ejemplo JSON), sino que también nos ponemos de acuerdo en la forma en la que se consultan estos datos.
REST es un intento para que todas las APIs que manejan recursos funcionen “más o menos parecido”, no es un protocolo como HTTP sino que es algo “menos formal”, es un conjunto de requerimientos, que si una API los cumple, entonces podemos decir que esta es una API REST. En la práctica esto hace que podamos asumir ciertas cosas sobre una API, sólo por el hecho de saber qué es REST, sin necesariamente conocer más detalles sobre ella. Como por ejemplo:
Para cerrar; API es una interfaz que nos permite que algún producto o servicio nuestro (nuestra propia “infraestructura” ) se pueda conectar con otros. Lo genial es que es sin la necesidad de saber cómo esos otros construyen y/o implementan sus funcionalidades, haciendo todo mucho más fácil y rápido.
Espero haber aclarado un poco tus dudas! De todas maneras recuerda que siempre lo más importante es la práctica y una vez que ya hayas hecho varias funcionalidades te recomiendo releer estas definiciones y verás cómo se siente la diferencia!