Antes de aprender a desarrollar software, API sonaba como una especie de cerveza.
Hoy en día utilizo el término con tanta frecuencia que, de hecho, recientemente intenté pedir una API en un bar.
La respuesta del camarero fue lanzar un 404: recurso no encontrado.
Conozco a muchas personas, tanto en tecnología como en otros lugares, que tienen una idea bastante vaga o incorrecta sobre lo que significa este término bastante común.
Técnicamente, API significa Interfaz de programación de aplicaciones . En algún momento u otro, la mayoría de las grandes empresas han creado API para sus clientes o para uso interno.
Pero, ¿cómo se explica la API en inglés sencillo? ¿Y hay un significado más amplio que el que se usa en desarrollo y negocios? Primero, retrocedamos y veamos cómo funciona la web.
WWW y servidores remotos
Cuando pienso en la Web, imagino una gran red de servidores conectados .
Cada página de Internet se almacena en algún lugar de un servidor remoto. Un servidor remoto no es tan místico después de todo, es solo una parte de una computadora ubicada remotamente que está optimizada para procesar solicitudes.
Para poner las cosas en perspectiva, puede poner en marcha un servidor en su computadora portátil capaz de servir un sitio web completo en la Web (de hecho, un servidor local es lo que los ingenieros usan para desarrollar sitios web antes de lanzarlos al público).
Cuando escribe www.facebook.com en su navegador, se envía una solicitud al servidor remoto de Facebook. Una vez que su navegador recibe la respuesta, interpreta el código y muestra la página.
Para el navegador, también conocido como cliente , el servidor de Facebook es una API. Esto significa que cada vez que visita una página en la Web, interactúa con la API de algún servidor remoto.
Una API no es lo mismo que el servidor remoto, sino que es la parte del servidor que recibe solicitudes y envía respuestas .
API como una forma de servir a sus clientes
Probablemente haya oído hablar de empresas que empaquetan API como productos. Por ejemplo, Weather Underground vende acceso a su API de datos meteorológicos.
Escenario de ejemplo: el sitio web de su pequeña empresa tiene un formulario que se utiliza para inscribir a los clientes en las citas. Desea brindarles a sus clientes la posibilidad de crear automáticamente un evento de calendario de Google con los detalles de esa cita.
Uso de API: la idea es que el servidor de su sitio web se comunique directamente con el servidor de Google con una solicitud para crear un evento con los detalles proporcionados. Su servidor luego recibiría la respuesta de Google, la procesaría y enviaría información relevante al navegador, como un mensaje de confirmación para el usuario.
Alternativamente, su navegador a menudo puede enviar una solicitud de API directamente al servidor de Google sin pasar por su servidor.
¿En qué se diferencia la API de Google Calendar de la API de cualquier otro servidor remoto?
En términos técnicos , la diferencia es el formato de la solicitud y la respuesta.
Para representar la página web completa, su navegador espera una respuesta en HTML, que contiene un código de presentación, mientras que la llamada a la API de Google Calendar solo devolvería los datos, probablemente en un formato como JSON .
Si el servidor de su sitio web realiza la solicitud de API, entonces el servidor de su sitio web es el cliente (similar a su navegador siendo el cliente cuando lo usa para navegar a un sitio web).
Desde la perspectiva de sus usuarios, las API les permiten completar la acción sin salir de su sitio web.
La mayoría de los sitios web modernos consumen al menos algunas API de terceros.
Muchos problemas ya tienen una solución de terceros, ya sea en forma de biblioteca o servicio. A menudo, es más fácil y más confiable utilizar una solución existente.
No es raro que los equipos de desarrollo dividan su aplicación en varios servidores que se comunican entre sí a través de API. Los servidores que realizan funciones auxiliares para el servidor de aplicaciones principal se denominan comúnmente microservicios .
En resumen, cuando una empresa ofrece una API a sus clientes, solo significa que han creado un conjunto de URL dedicadas que devuelven respuestas de datos puros, lo que significa que las respuestas no contendrán el tipo de sobrecarga de presentación que cabría esperar en un interfaz gráfica de usuario como un sitio web .
¿Puede realizar estas solicitudes con su navegador? A menudo, sí. Dado que la transmisión HTTP real ocurre en texto, su navegador siempre hará lo mejor que pueda para mostrar la respuesta.
Por ejemplo, puede acceder a la API de GitHub directamente con su navegador sin siquiera necesitar un token de acceso. Aquí está la respuesta JSON que obtiene cuando visita la ruta de la API de un usuario de GitHub en su navegador (//api.github.com/users/petrgazarov):
{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//petrgazarov.com/", "location": "NYC", "email": "[email protected]", "hireable": null, "bio": null, "public_repos": 23, "public_gists": 0, "followers": 7, "following": 14, "created_at": "2013-10-01T00:33:23Z", "updated_at": "2016-08-02T05:44:01Z"}El navegador parece haber funcionado bien mostrando una respuesta JSON. Una respuesta JSON como esta está lista para usar en su código. Es fácil extraer datos de este texto. Entonces puedes hacer lo que quieras con los datos.
A es para "Aplicación"
Para cerrar, incluyamos un par de ejemplos más de API.
“Aplicación” puede referirse a muchas cosas. Éstos son algunos de ellos en el contexto de API:
- Un software con una función distinta.
- Todo el servidor, toda la aplicación o solo una pequeña parte de una aplicación.
Básicamente, cualquier pieza de software que pueda separarse de forma distintiva de su entorno, puede tener una "A" en la API y probablemente también tendrá algún tipo de API.
Digamos que está utilizando una biblioteca de terceros en su código. Una vez incorporada a su código, una biblioteca se convierte en parte de su aplicación general. Al ser una pieza de software distinta, la biblioteca probablemente tenga una API que le permita interactuar con el resto de su código.
Aquí hay otro ejemplo: en el diseño orientado a objetos , el código se organiza en objetos. Su aplicación puede tener cientos de objetos definidos que pueden interactuar entre sí.
Cada objeto tiene una API, un conjunto de propiedades y métodos públicos que utiliza para interactuar con otros objetos en su aplicación.
An object may also have inner logic that is private, meaning that it’shiddenfrom the outside scope (and not an API).
From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.
Interesting Resources (stuff that I left out but is still very cool):
A great youtube video on DNS (Domain Name System)
HTTP protocol basics
An Awesome Khan Academy video on Object Oriented Design Principles