Por Damián Wajser, Technical Team Lead Softtek
Como sabemos, internet se basa en una comunicación constante entre clientes y servidores, por lo cual, que esta comunicación sea lo más eficaz posible es el reto que debemos afrontar y el objetivo de todas las arquitecturas, tecnologías y lenguajes web.
Hace ya varios años los servicios webs no han parado de aumentar y mejorar, seguramente te topaste con el término RestFul en varias ocasiones. Sin embargo no es un término para nada nuevo.
Rest (Representational state transfer), es un producto del siglo XX, lo cual en este ámbito se considera antiguo. Este producto, es un modelo de arquitectura web basado en el protocolo HTTP, que se nutre con un conjunto de buenas prácticas para mejorar las comunicaciones cliente-servidor.
Principios de la arquitectura REST
El primero de estos principios es saber que todo lo que se mueve a través de las comunicaciones web es un recurso. Para entenderlo tenemos que partir de la idea que los datos se representan con el formato específico que tienen y no como un archivo físico.
Cada recurso disponible en internet tiene un formato en particular que se describe por el tipo de contenido: Jpeg para imágenes, mpeg para video, xml, html, entre otros, los cuales van a estar referidos en los protocolos de comunicación como: image/jpeg, video/mpeg, text/html, text/xml, etc.
El segundo principio que tenemos que tener en cuenta, es que cada uno de estos recursos debe tener un identificador único, el cual va a estar dado por su URL, ya que hay una infinidad de recursos en la web y los mismo deben estar accesibles e identificables.
En tercer lugar, es que este protocolo de transmisión de datos debe utilizar los verbos estándares de HTTP, que están definidos en el protocolo nativo, donde cada uno de estos verbos significa una acción diferente. Hay definidas 8 acciones principales: GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECT.
El cuarto principio y clave en este tipo de arquitectura es, que cada recurso puede tener múltiples representaciones, independientemente de como esté almacenado. Un ejemplo sencillo para ilustrar este principio sería tener un recurso en formato XML y poder solicitarlo en JSON.
El quinto principio es clave para entender las comunicaciones cliente-servidor, se trata de comunicaciones que se denominan sin estado (STATELESS), lo que significa que cada petición al servidor es tratada de manera totalmente independiente.
REST es antiguo, entonces, ¿porque ganó tanta popularidad últimamente?
La razón básicamente se encuentra en la popularización de los Web Services y la enorme ampliación de sus usos, lo que hizo que el protocolo SOAP (que predominaba hasta el momento) no sea el más eficaz.
El protocolo SOAP (Simple Object Access Protocol), se basa en distintas especificaciones WS que aprovechan la flexibilidad del XML. Esto permitió que se definan un gran número de ellas. A su vez están vagamente definidas, lo que se buscaba con esto es convertirse en interoperables entre distintos proveedores, y llevó a que sean unificadas por otra especificación como WS Basic Profile.
WS Basic Profile es la encargada de definir todas las reglas de interoperatibilidad para todas las especificaciones SOAP que son transportadas.
Ademas, por mas que estemos utilizando SOAP como protocolo seguimos utilizando HTTP como medio de transporte, por lo cual para enviar datos binarios como archivos o imagenes, entre otros, se necesitó incorporar nuevas especificaciones como SWAREF y MTOM.
Ahí es donde reaparece REST simplificando nuevamente las cosas, y reintroduciendo el concepto de recursos y medios estándar.
Cabe aclarar que cuando hablamos de Rest y RestFull no hablamos de conceptos diferentes, sino que es lo mismo, salvo ciertos matices.
Rest, como hablamos anteriormente, es un concepto de arquitectura que siguen los principios anteriormente mencionados, en cambio RestFull son los web services que siguen esos principios.
Ventajas de utilizar REST
- Separación de un recurso de su representación
Recordemos que un recurso es solo un conjunto de información y como hemos definido anteriormente en los principios REST puede tener múltiples representaciones.
Igualmente recordemos que es recurso no tiene estado, corresponde a quien lo llama especificar en el encabezado de la petición HTTP el tipo de contenido que se desea obtener.
Una vez recibido este requerimiento, será la aplicación del servidor la encargada de manejar la representación y devolver el estado HTTP apropiado:
HTTP 200: para mensajes OK.
HTTP 400: cuando un recurso no está disponible.
HTTP 500: Por un error interno del lado del servidor.
Por lo cual deberíamos enviarle al servidor (en la cabecera HTTP, con la propiedad acept) que es lo que esperamos recibir, por ejemplo:
text/xml
application/json
jpg/jpeg
etc.
- Visibilidad
Rest está diseñado para ser visible y simple, lo que significa que cada aspecto del servicio debe ser autodescriptivo siguiendo las normas HTTP, que hablamos anteriormente.
Seguridad.
Al utilizar rest garantizamos que los métodos http son seguros, lo que significa que a solicitar un recurso este requerimiento no modifica o causa ningún tipo de cambio en su estado.
- Escalabilidad
Si el aumento de la demanda exige aumentar el número de servidores, esto puede hacerse sin preocuparse por la sincronización entre los mismos, ya que no deberíamos tener que preocuparnos por el estado de los recursos.
- Rendimiento
La escalabilidad no debe ser confundida con el rendimiento.
El rendimiento se mide por el tiempo necesario para que una única petición sea procesada, mientras que la escalabilidad depende del número total de peticiones que la aplicación puede manejar.
Al ser pequeños servicios el tiempo de respuesta es 0 o con tendencia a 0, porque estos servicios no deberían ejecutar gran lógica de negocio, con esta arquitectura estamos aprovechando el poder de procesamiento de las máquinas cliente para usar su poder de procesamiento.
Te invito a dejar tu opinión.
