API y API RESTful qué son y las principales diferencias

Vivimos en un mundo donde todos están interconectados entre ellos, donde en pocos segundos conseguimos mandar un mensaje a una persona que está incluso a miles de kilómetros y donde, cómodamente desde la cama con nuestro smartphone, podríamos incluso programar encender la máquina del café; pero ¿cómo ocurre esta conexión?

¿Cómo permiten esto los diferentes dispositivos (tablet, pc, smartphone) y las aplicaciones? 

Concretamente, ¿cómo conseguimos hacer todas estas operaciones?

El héroe silencioso y poco citado que te permite hacer todo esto son las Application Programming Interface o mejor conocidas como API. 

¿Pero entonces qué son las API?

API, como hemos ya mencionado, es el acrónimo de Application Programming Interface, que traducido significa Interfaz para la programación de aplicaciones. Simplificando mucho, representando un conjunto de proceduras que sirven para comunicar dos o más aplicaciones entre ellas.

Podéis imaginar las API como un intermediario de la programación, a través del cual podemos utilizar otros productos o servicios sin saber nada de su implementación.  

Haciendo referencia a este último ejemplo, pensad que cualquier lenguaje de programación, por ejemplo JAVA o PHP, en este caso hablando de API nos referimos a sus bibliotecas software, o sea el conjunto de funciones o estructuras de datos que ese lenguaje nos ponga a disposición. Otro ejemplo son las API que permiten la comunicación entre el ratón y el teclado y los componentes hardware de nuestro pc.

Hagamos un último ejemplo no conectado con el mundo informático: 

Imagínate ir a un restaurante y pedir comida o pedir información sobre un plato. Seguramente para realizar una de estas acciones tienes que interactuar con un camarero, dirigiéndote a él incluso para pedir y pagar la cuenta o otras informaciones del menú.

Pensad un poco, a través del camarero conseguimos comer un buen plato en un restaurante, sin saber las cosas complicadas que hay detrás de su preparación, como: el uso de los ingredientes correctos, los tipos de platos y sartenes que hay que utilizar o incluso la gestión de las reservas de alimentos para garantizar la constante preparación de los platos durante la jornada.

El camarero representa la interfaz entre nosotros clientes y todos los servicios del restaurante, por lo que puede ser visto como la API del restaurante.

¿Ahora has entendido por qué las API son tan útiles? 

Nos facilitan la vida, convirtiendo la integración y el uso de servicios externos mucho más fácil.

¿Qué diferencia hay con las API REST?

Para explicar las diferencias entre las API y las API REST, empiezo diciendo que:

No todas las API son REST, pero todos los servicios REST son API.

La palabra REST, acrónimo de Representational State Transfer que podríamos traducir como transferencia del estado, indica un conjunto de principios arquitectónicos definidos por primera vez en la tesis de Roy Fielding, discutido en la Universidad de California, en Irvine en el 2000.

El enfoque REST está basado en seis principios: 

• Arquitectura Client-Server
• Comunicación Stateless, donde no se guarda contenido del cliente en el servidor entre solicitudes
• Caching de los contenidos para eliminar algunas interacciones entre client y server
• Sistema a niveles, para admitir interacciones entre client y server, añadiendo características adicionales como el equilibrio de carga
• Interfaz uniforme para los componentes, esto garantiza que las informaciones transmitidas respeten siempre una forma standard
• Código on demand, este principio es opcional, prevé que el server devuelva el código ejecutable al cliente para expandir su funcionalidad.

Pero más allá de estos principios, el elemento fundamental del enfoque REST son los recursos. Por recursos se entiende cualquier dato o información recuperable de manera única. En el ámbito Web el mecanismo utilizado para recuperar los recursos es el uso de URI que se basan en llamadas HTTP. 

Estas llamadas necesariamente deben hacerse con un verbo HTTP, como POST, GET, PUT y DELETE, y es así en estos verbos donde se basa el concepto que todos conocen como API RESTful. Para cada verbo viene asociada una operación CRUD: create, read, update e delete.

Ahora es fácil entender porque el enfoque REST funciona tan bien con la web, de hecho si REST señala un sistema para organizar las interacciones entre un client y server, el HTTP sin embargo es el protocolo que permite el envío concreto de estos datos.

Como he dicho antes, todos estos datos o recursos identificados a través de un URI específico, por ejemplo la dirección que podéis ver arriba de este sitio identifica únicamente este artículo.

Otros ejemplos son:

• www.sito.it/blog identificará únicamente la sección blog de un determinado sitio
• www.sito.it/blog/articolo-1 identificará únicamente un artículo en la sección de un blog de ese sitio.

Antes he hablado de verbos HTTP (POST, GET, PUT y DELETE), porque se utilizan también para comunicar al server que hacer con ese específico recurso.

Me explico mejor: 

MÉTODO POST

Se usa comúnmente para comunicar al servidor la finalización de una operación específica, por ejemplo, para activar el desencadenador de otros scripts. Si es necesario, puede contener un paquete de información para pasar al servidor.

A menudo se usa mucho en lugar del método PUT para actualizar datos.

MÉTODO GET

Es el método que el buscador aplica de default para cada una de nuestras peticiones, para entendernos, cuando navegamos en un sitio web o hacemos clic en un enlace estamos efectuando una GET hacia ese recurso.

MÉTODO PUT

Según los principios REST tendría que ser usado para crear o actualizar un dato. Por ejemplo si llamáramos PUT/blog/artículo-2 estamos comunicando al server querer crear un nuevo artículo, llamado artículo-2.

MÉTODO DELETE

Es el contrario del PUT, se invoca cuando desea eliminar un recurso del servidor.

Tendríamos que añadir otras informaciones importantes sobre el método HTTP, pero necesitaríamos dedicar un artículo entero solo a eso. En esta ocasión me he limitado solo a explicar su conexión con los principios REST.

Pero, ¿estamos seguros que las API que estamos creando son verdaderamente efectivas RESTful?

Desafortunadamente el enfoque REST, aún siendo uno de los más famosos y usados en época moderna, sigue siendo uno de los más incomprendidos.

REST, que significa Representational State Transfer o sea transferencia del estado, no tiene relación con las operaciones que usan métodos HTTP para efectuar CRUD en la base de datos.

Solo hace falta leer con atención los principios descritos y notaréis que no han sido citados en el uso de los métodos HTTP como ocurre con clientes que se consideran RESTful.

Los servicios HTTP que nosotros creemos o a los que accedemos en nuestras aplicaciones se denomina WEB API o también WEB SERVICES API. El punto sobre el que se concentran no es la transferencia del estado, como señala el enfoque REST, si no la gestión remota de los recursos a visualizar, modificar o crear.

Entonces incluso si se ha convertido de uso común definir nuestras WEB API como servicios REST, en realidad es equivocado, ya que la implementación de un correcto enfoque REST requiere que el client no conozca desde el principio todos los recursos, si no que conozca solo el entry point de las API, o sea los URL o LINK iniciales y que sucesivamente sea el server el que gestione las transiciones de estado, enviando al client los hipervínculos entre un recurso y otro. Este dato puede pasar también a través de un archivo normal JSON que contenga en su interior los LINK que el cliente podrá seguir.