El Estándar RESTful

A medida que avanza la tecnología y al ver que cada día tenemos más equipos y servicios interconectados, no nos detenemos a pensar ¿cómo lo hacen?, simplemente hacemos uso de estos equipos y servicios. Sin embargo, ¿qué si queremos crear una red de equipos y servicios interconectados para una empresa, nuestro producto o simplemente para simplificar su estructura? El análisis e investigación de cómo lograr este objetivo conllevan al mismo término: Las API’s Restful o cómo de forma general es conocido: API. En esto básicamente se basa el estándar restful.

Ahora bien, en este artículo se lleva a cabo la explicación de dos conceptos fundamentales para entender de lo que realmente se trata este tema. El primer concepto será el de las APIs, y el segundo será el tipo de API de servicios web específico, REST. Asimismo, se contrasta el API SOAP que es muy común entre los desarrolladores en conjunto con el API RESTful.

¿Qué es una API?

Una API (Application Programming Interface – Interfaz de Programación de Aplicaciones) es un conjunto de funciones y procedimientos que cumplen una o muchas funciones con el fin de ser utilizadas por otro software. Ésta facilita la relación entre dos aplicaciones para el intercambio de mensajes o datos. Un conjunto de funciones y procedimientos que ofrece una biblioteca para que otro software la utilice como capa de abstracción mediante el formato estándar de JSON o XML.

La Figura muestra un ejemplo del cómo funciona una API, en este caso se muestra la misma como un proveedor de acceso universal a cualquiera de los recursos de datos y software denominados como también Assets, para que el desarrollador construya según su criterio una aplicación web o móvil, como se aprecia en la figura, de tal modo que pueda ser usada por usuarios finales que tendrán la experiencia de tener acceso a información de distintos sitios, solo en una app.

Ilustremos otro ejemplo de una aplicación web. Digamos que se necesita hacer peticiones HTTP. En lugar de desarrollar todo el código para hacer una petición HTTP, se puede utilizar una API que se encargue de esto, como por ejemplo si se necesita utilizar archivos .yaml, se puede usar la API Yaml de Ruby.

Ahora, cada API está diseñada en un lenguaje de programación concreto y con unas especificaciones distintas que la definen (las APIs pueden incluir especificaciones para estructura de datos y rutinas, clases de objetos o variables, a partir de las cuales se basa el uso de tal interfaz). Además, suele ser habitual que cada una de ellas disponga de documentación completa y eficaz (un conjunto de tutoriales, manuales y reglas de buenas prácticas para esa interfaz de programación).

Tipos de API

APIs de servicios web

Estas son las interfaces de desarrollo de aplicaciones que permiten el intercambio de información entre un servicio web (software que da acceso a un servicio concreto a través de una URL) y una aplicación. Normalmente ese intercambio se producen mediante peticiones HTTP o HTTPS (la versión cifrada del protocolo HTTP) [1]. En la petición de la aplicación y respuesta, también se contiene información de todo tipo normalmente en dos tipos de formatos muy usados y como se dijo anteriormente, en XML o JSON.

Ahora bien, existen cuatro tipos de APIs de servicios web que se deben abordar y que son habituales en los desarrolladores: SOAP (Simple Object Access Protocol), un protocolo estándar de intercambio de información y de datos en XML entre dos objetos; XML-RPC, un protocolo de llamada a procedimiento remoto que usa XML como formato de datos y llamadas HTTP como sistema de comunicación; JSON-RPC, mismo sistema de comunicación pero en formato JSON; y REST (Representational State Transfer), arquitectura de software para sistemas hipermedia en la World Wide Web (www); una API REST usa el protocolo HTTP.

APIs basadas en bibliotecas

Este tipo de APIs son las que permiten que una aplicación importe una biblioteca de otro software para hacer el intercambio de información. Hoy día gran parte de las bibliotecas que dan acceso a productos y servicios están diseñadas en JavaScript. Las APIs en JavaScript suelen ser un ejemplo ilustrativo de APIs basadas en bibliotecas, por ejemplo las que se utilizan dentro del mercado de la cartografía web. (Servicios como Google Maps y Leaflet para creación de mapas iterativos en la web).

APIs basadas en clases

Este tipo de interfaces de desarrollo de aplicaciones permite la conexión con los datos en torno a las clases, como es habitual en programación orientada a objetos (POO) con java. La API de Java usa clases abstractas para la creación de aplicaciones igual que cualquier programa desarrollado en este lenguaje. Esas clases proporcionan todo lo necesario para realizar todo tipo de funciones dentro de esas aplicaciones. La interfaz de desarrollo de Java se organiza en paquetes y cada uno de esos paquetes contiene a su vez un conjunto de clases relacionadas entre sí.

APIs de funciones en sistemas operativos

Los programas de software están continuamente interactuando con los sistemas operativos. En muchos casos, la forma en la que lo hacen es a través de APIs. Sistemas operativos como Windows disponen de APIs que permiten esa comunicación entre programas y el OS. Por ejemplo: interfaz de usuario, acceso y almacenamiento de datos, mensajería, gráficos y multimedia, diagnóstico de errores, entre otros.

Para efectos de este artículo, se aborda básicamente el tema referente a las APIs web services (servicios web) en específico el REST.

¿Qué es REST?

REST deriva de “REpresentational State Transfer”, que traducido significaría “Transferencia de representación de estado”. Un servicio REST no posee estado, he de aquí la radicación de su nombre, lo que implica que entre dos llamadas cualesquiera, el servicio pierde todos sus datos.

Es considerada una técnica de arquitectura de software, es decir, un conjunto de principios y patrones de comunicación que ayudan a crear una forma de pensar y construir las APIs. Este tipo de arquitectura se define por un conjunto de restricciones entre los elementos, componentes, conectores y datos usados.

La definición formal de la técnica se describe de la siguiente forma:

Un modelo cliente-servidor, es una interfaz uniforme que separa a cliente y servidor. Haciendo que ambas partes sean completamente independiente, pudiendo ser reemplazadas de forma transparente para la otra parte.
Un protocolo sin estado (o stateless), cada petición HTTP realizada debe contener toda la información necesaria para poder resolverla, esto permite que ni el cliente ni servidor necesiten recordar ningún estado previo. Sin embargo, existen algunas excepciones y existen algunas aplicaciones HTTP que incorporan la memoria caché, para que así, el cliente pueda ejecutar en un futuro la misma respuesta para peticiones idénticas. Además debe ser idempotente, por lo que la misma petición, con los mismos parámetros, debería devolver el mismo resultado. Cabe destacar, que el hecho de que sea sin estado implica que no se puede llamar un servicio REST y suministrarle datos y esperar que “nos recuerde” en la siguiente petición. El estado lo mantiene el cliente, y es el mismo quién debe pasar el estado en cada petición. Si se quiere que un servicio REST recuerde ciertos datos, debo suministrarle la identidad de quién pide el servicio en cada llamada. Eso puede ser un usuario y una contraseña, un token o cualquier otro tipo de credenciales
Cacheable, y donde cada petición debe indicar si el resultado de la misma puede ser o no cacheado. Un sistema correcto de cacheo, tanto parcial como completo, ayudará en gran medida a la escalabilidad y rendimiento.
Las operaciones más importantes relacionadas con los datos en cualquier sistema REST y la especificación HTTP son cuatro: POST (crear), Get (leer y consultar), PUT (modificar) y DELETE (borrar).
Una interfaz uniforme que represente de forma única los recursos, por ejemplo mediante el uso de URIs [2] únicas, y que permita la manipulación de dichos recursos a través de dichas representaciones. Además esta interfaz debe incorporar mensajes autos descriptivos junto con un uso correcto de los códigos de estado HTML.
Una técnica basada en el uso de hipermedios como motor para poder indicar las diferentes acciones. El uso de estos sirve para explicar la capacidad de una interfaz de desarrollo de aplicaciones para proporcionar al cliente y al usuario los enlaces adecuados, y ejecutar acciones concretas sobre los datos.

Asimismo es una extensión del concepto de hipertexto. Ese concepto llevado al desarrollo de páginas web es lo que permite que el usuario pueda navegar por el conjunto de objetos a través de enlaces HTML.

Para cualquier API REST es obligatorio disponer del principio HATEOAS (Hypermedia As The Engine Of Application State – Hipermedia Como Motor del Estado de la Aplicación) para ser una verdadera API REST. Este principio es el que define que cada vez que se hace una petición al servidor y éste devuelve una respuesta, parte de la información que contendrá serán los hipervínculos de navegación asociada a otros recursos del cliente.

Devolución de una petición a una API REST según el principio HATEOAS (link a un tutorial explicativo del concepto de hipermedia en API REST con un ejemplo práctico de una petición a una base de datos de automóviles). También se puede observar este VIDEO

Figura donde se muestra una petición aplicando el principio descrito anteriormente.

Ahora ya descritos ambos conceptos por separado, podremos entonces realizar una conceptualización de lo que son las APIs RESTful. Cabe destacar que REST básicamente es una arquitectura que se ejecuta sobre HTTP y las APIs RESTful hacen referencia a un servicio web que implementa la arquitectura REST.

¿Qué es una API RESTful?

Es un servicio que funciona como un estándar para compartir información, en un sistema de doble vía: Consulta y Respuesta (Request => Response).

Al consultar una API se deben especificar parámetros de consulta para que el servicio sepa lo que queremos consultar, basado en una estructura previamente definida provista por el API por medio de una documentación.

La arquitectura REST al trabajar sobre el protocolo HTTP, los procedimientos o métodos de comunicación son los mismos que HTTP, siendo los principales: GET, POST, PUT, DELETE. Otros métodos que se utilizan en RESTful API son OPTIONS y HEAD. Este último se emplea para pasar parámetros de validación, autorización y tipo de procesamiento, entre otras funciones.

Otro componente de un RESTful API es el “HTTP Status Code”, que le informa al cliente o consumidor del API que debe hacer con la respuesta recibida. Estos son una referencia universal de resultado, es decir, al momento de diseñar un RESTful API toma en cuenta utilizar el “Status Code” de forma correcta.

Por ejemplo, el código 200 significa OK, que la consulta ha recibido respuesta desde el servidor o proveedor del API. Los códigos de estado más utilizado son:

§ 200 OK
§ 201 Created (Creado)
§ 304 Not Modified (No modificado)
§ 400 Bad Request (Error de consulta)
§ 401 Unauthorized (No autorizado)
§ 403 Forbidden (Prohibido)
§ 404 Not Found (No encontrado)
§ 422 (Unprocessable Entity (Entidad no procesable)
§ 500 Internal Server Error (Error Interno de Servidor)

Ejemplo de una respuesta de una RESTful API:

Por lo general y mejor práctica, el cuerpo (Body) de la respuesta de un API es una estructura en formato JSON. Aunque también puede ser una estructura XML como la usada por defecto en las APIs que usan SOAP, o incluso puede ser usadas estructuras personalizadas. Sin embargo, como el objetivo es permitir que cualquier cliente pueda consumir el servicio de un API, lo ideal es mantener una estructura estándar, por lo que JSON es la mejor opción.

Un ejemplo de una respuesta en JSON está dada como sigue:

La respuesta anterior se obtiene al consultar un API por medio de una ruta o método especifico vía URL. Por ejemplo: http://localhost/api/v1/autos utilizando el método HTTP GET.

SOAP VS REST

En el siguiente enlace se muestran algunas de las diferencias entre ambos servicios para APIs, importantes de saber a la hora de seleccionar el más acorde a lo que queremos realizar.

SOAP vs. REST

Las APIs representan un punto importante al momento de realizar alguna petición en cualquier formato específico del servicio que se solicite. En general, son un avance en todos los sentidos pues permiten ahorro de código a implementar y tiempo a utilizar para llevar a cabo la tarea. Es una modalidad que debe estar siempre presente en cualquier aplicación web, pues se ha vuelto ya algo básico e imprescindible al momento de realizar una petición o utilizar datos de otra aplicación.

Publicado el 18 de septiembre de 2019