¿Qué es la API? Explicación breve y sencilla

El tema de la API es muy interesante y extenso, por lo que he dividido el material en tres partes, cada una de ellas destinada a un público diferente. Si estás empezando a entender el tema, lee todo en orden. Y si ya sabes algo, elige la parte que te interesa.

1. Explicación sencilla de la API (este artículo 👇)
2. El mejor marco de trabajo para API
3. Construir API con FastAPI (próximamente)
4. Construir API con ChatGPT (próximamente)
5. Herramientas para probar API (próximamente)
6. Gane dinero con la API (próximamente)

Así que, vamos…

¿Qué es la API?

API significa Application Programming Interface o Interfaz de Programación de Aplicaciones. En el artículo que sigue sólo utilizo “API”.

Los profesionales definen la API como un contrato de servicios entre dos aplicaciones. Es decir, como cualquier contrato normal, que especifica cómo deben interactuar las aplicaciones (programas, servicios) entre sí, cómo deben formular sus peticiones y qué esperar como respuestas. Por cierto, los buenos desarrolladores siempre describen todo esto en la documentación de la API.

Además de la documentación normal, he aquí otras características importantes de una buena API:

• Fácil de entender cómo funciona
• Fácil de usar, incluso sin documentación
• Difícil de utilizar de forma incorrecta (a prueba de tontos)
• Fácil de leer y mantener el código que utiliza la API
• Suficientemente potente para cumplir los requisitos
• Fácil de escalar y añadir funcionalidad
• Cumple las expectativas del usuario

¿Cómo funcionan las APIs?

Las API suelen explicarse como una interacción cliente-servidor. La aplicación que envía la petición se llama cliente y la que envía la respuesta se llama servidor. La API proporciona la comunicación entre los servicios a través de bucles de solicitud-respuesta. Los bucles pueden requerir o no una conexión a Internet.

Las aplicaciones intercambian estas peticiones, respuestas y datos siguiendo unas reglas especiales que rigen el uso y la aplicación de dichas llamadas, definen los comandos y tipos de datos aceptados y establecen ciertas normas de uso de la API. Un conjunto de estas reglas se denomina protocolo.

Protocolos de la API

A principios de la década de 2000, sólo había dos protocolos de API reales que la mayoría de los desarrolladores debían conocer: SOAP y REST. Sin embargo, en los últimos años han aparecido muchos protocolos nuevos, como las nuevas implementaciones de RPC, GraphQL, Thrift y otros. A continuación se explica un poco más sobre algunos de ellos.

SOAP

SOAP (Simple Object Access Protocol) utiliza archivos XML para transferir datos entre servicios web. Los archivos XML se transfieren a través de HTTP/HTTPS. SOAP también proporciona cierta flexibilidad al permitir la transferencia de datos a través de otros protocolos, como el Protocolo de Control de Transmisión (TCP), el Protocolo Simple de Transporte de Correo (SMTP), el Protocolo de Datos de Usuario (UDP), etc.

Aunque SOAP sigue siendo el más extendido y estable, su popularidad ha sido recientemente inferior a la de los protocolos más nuevos.

RPC

RPC (Remote Procedure Call) es todo un grupo de formas de describir cómo diferentes ordenadores pueden comunicarse entre sí. Este sistema existe desde los años 70. En resumen, el cliente ejecuta una función (o procedimiento) en el servidor y éste le devuelve el resultado. Técnicamente, el protocolo SOAP es un ejemplo de RPC.

Las siguientes implementaciones del protocolo RPC están actualmente en uso:

• JSON-RPC, creado a mediados de la década de 2000, utiliza ampliamente el formato JSON, pero sólo admite un pequeño conjunto de comandos y no ofrece la flexibilidad de otros protocolos. Sin embargo, si tienes un caso de uso simple de la API, este protocolo puede ser una buena solución.
• XML-RPC se diferencia de JSON-RPC únicamente en que los datos se transfieren como archivos XML. El vocabulario XML incorporado se utiliza para crear consultas y respuestas. El cliente define el procedimiento y los parámetros en la solicitud, y el servidor envía una respuesta que puede contener datos o una descripción del error.
• gRPC es aún más nuevo, fue publicado por Google en 2015, y también utiliza HTTP como capa de transporte. Utiliza el formato ProtoBuff para transferir datos. A diferencia de otros protocolos, gRPC permite a los desarrolladores definir las llamadas a funciones que deseen, en lugar de elegir entre opciones predefinidas (como GET y PUT en el caso de REST).

REST

REST (Representational State Transfer) es uno de los más populares hoy en día. Aunque hay que dejar claro desde el principio que REST no es un protocolo, lo que significa que no tiene reglas claras y generalmente aceptadas. REST es sólo un enfoque o, en otras palabras, un conjunto de recomendaciones al desarrollador sobre cómo organizar mejor la interacción de los componentes de su aplicación en la red. Por eso encontrarás todo tipo de diferentes formas de implementar estas recomendaciones, qué métodos utilizar, qué código devolver, etc., dependiendo de la situación.

Las principales características de la API REST son que cada petición del cliente (petición REST) al servidor ya contiene toda la información sobre lo que el cliente quiere en la respuesta (el estado representativo deseado) del servidor, y que el servidor no tiene que guardar los datos del cliente (información de la sesión del cliente) entre diferentes peticiones.

Las peticiones del cliente al servidor son similares a las URL que se introducen en un navegador para abrir un sitio web. La respuesta del servidor son simples datos sin visualización gráfica de la página web.

Es posible que también te hayas encontrado con el término RESTful. Suele describir los servicios web construidos teniendo en cuenta las recomendaciones REST. Hay un total de seis requisitos obligatorios (restricciones) para construir aplicaciones REST distribuidas:

1. Modelo cliente-servidor. La aplicación debe utilizar la arquitectura cliente-servidor. Separar las necesidades del cliente de las del servidor con los datos aumenta la portabilidad del código y la escalabilidad de toda la aplicación.
2. Sin Estado. Ninguna información del estado del cliente se almacena en el servidor entre las peticiones del cliente. Todas las peticiones deben ser diseñadas para que el servidor reciba toda la información que necesita para ejecutar la petición.
3. Caché. Los clientes pueden almacenar en caché las respuestas del servidor. Las respuestas del servidor, a su vez, deben ser marcadas explícita o implícitamente como cacheables o no cacheables para evitar que los clientes reciban datos obsoletos o incorrectos.
4. Unificación de la interfaz. La aplicación de la unificación de la interfaz de los componentes simplifica la arquitectura del sistema y mejora la transparencia de las interacciones de los componentes. Pero puede reducir la eficiencia porque la información se transmite sólo de forma estándar.
5. Sistema multicapa. El uso de servidores intermedios (“capas” en la estructura jerárquica de la red) puede mejorar la escalabilidad debido al equilibrio de la carga y al almacenamiento en caché distribuido.
6. Código a la carta. REST le permite ampliar la funcionalidad del cliente descargando y ejecutando código en forma de applet o script. Esto simplifica el cliente porque puede reducir el número de funciones que deben implementarse de antemano.

Las ventajas de REST son, entre otras, la fiabilidad, el rendimiento (gracias a la caché), la escalabilidad, la facilidad de uso, el soporte y la adaptación a las nuevas necesidades que vayan surgiendo.

GRAPHQL

GraphQL (Graph Query Language) fue desarrollado en Facebook y lanzado en 2015. Es un intento de superar algunas de las limitaciones e imperfecciones de REST.

La principal ventaja de GraphQL es que el propio cliente determina los datos y el formato deseados en su petición, y GraphQL devuelve los datos en el mismo formato. Esto ahorra tiempo y memoria porque la respuesta del servidor es sólo la mínima, es decir, sólo los datos que se necesitan, en lugar de archivos ya preparados con mucha información que debe ser procesada posteriormente.

También reduce el número de peticiones HTTP en sí, ya que GraphQL permite consultar varias bases de datos, microservicios y otras APIs con un único punto final de GraphQL.

APACHE THRIFT

Apache Thrift, al igual que GraphQL, fue creado en Facebook. Fue desarrollado con un enfoque en dos objetivos principales: permitir la interoperabilidad con servicios escritos en diferentes lenguajes, y escalabilidad.

Esencialmente, es una implementación de RPC que utiliza un mecanismo de generación de código combinado con una pila de software para crear una API. La pila ayuda a escribir código para el lado del cliente y del servidor. La sintaxis del código es flexible e intuitiva. Un mecanismo especial genera código en cualquier lenguaje de programación que el desarrollador elija.

La principal ventaja de Thrift es la facilidad con la que permite cambiar el protocolo utilizado por un servicio una vez definido éste. Combinado con el hecho de que Thrift también soporta muchos métodos de transporte diferentes y varias implementaciones de procesos de servidor diferentes, esto significa que Thrift es muy adecuado para situaciones en las que se necesita cambiar o actualizar la arquitectura y la implementación de la API con frecuencia.

Por otro lado, la flexibilidad que proporciona Thrift a la hora de elegir cómo implementar la API puede llevar a una menor organización y consistencia que con otros protocolos de API que ofrecen sólo una manera de hacer las cosas.

Dónde se usan las APIs

Las API son omnipresentes en la forma en que las aplicaciones interactúan entre sí y con diversos servicios en línea. Tan omnipresentes que si se desconectan todas las APIs a la vez, casi todos los servicios de Internet y la mayoría de las aplicaciones a las que se está acostumbrado simplemente dejarán de funcionar.

Con una API, los programadores pueden aprovechar las aplicaciones de terceros sin tener que escribir y mantener su propio código para la tarea. Por ejemplo, si tu aplicación debe mostrar el tiempo, es más fácil utilizar la API meteorológica disponible públicamente para proporcionar esa información a tus usuarios que escribir tu propio código meteorológico desde cero.

Otros ejemplos de este tipo de servicios son API de registro de usuarios, servicios de sistemas de pago, redes sociales y muchos otros. Hablaré más de esto en la tercera parte.

Ahora que entendemos qué es una API y cómo funciona todo, vamos a ver las herramientas que puedes utilizar para escribir tu API de forma rápida y eficiente.

Parte 2 - Cómo escribir tu API - ¡próximamente!

Parte 3 - Cómo ganar dinero con las API - aún estoy trabajando en el artículo.

😎