11Ago
rest apis
Por: E. Alex García Agosto 11, 2017 En: Noticias y Eventos Comentarios: 0

En la actualidad, el enfoque SOAP (Simple Object Access Protocol) para el desarrollo de APIs web es cada vez menos empleado, pues se podría decir que no existe proyecto o aplicación que no disponga de una API REST (Representational State Transfer – Transferencia de Estado Representacional) para la creación de servicios profesionales. Twitter, YouTube y Facebook, son algunas de las cientos de empresas que generan negocio gracias a REST y las APIs  basadas en REST.

REST cambió por completo la ingeniería de software a partir del 2000. Este nuevo enfoque de desarrollo de proyectos y servicios web fue definido por Roy Fielding, uno de los padre de la especificación HTTP y uno los referentes internacionales en todo lo relacionado con la Arquitectura de Redes, en su disertación ”Architectural Styles and the Design of Network-based Software Architectures”. En el campo de las APIs, REST es, a día de hoy, el alfa y omega del desarrollo de servicios de aplicaciones.

Buscando una definición sencilla, REST es cualquier interfaz entre sistemas que use HTTP para obtener datos o generar operaciones sobre esos datos en todos los formatos posibles, como XML y JSON. Es una alternativa en auge a otros protocolos estándar de intercambio de datos como SOAP, que disponen de una gran capacidad pero también mucha complejidad. A veces es preferible una solución más sencilla de manipulación de datos como REST.

REST no es una tecnología, ni siquiera una arquitectura, REST es un estilo arquitectónico. Es un conjunto de restricciones a respetar cuando diseñamos la arquitectura de un servicios web.

¿Cuáles son los principios de REST?

El estilo de arquitectura subyacente a la Web es el modelo REST. Los objetivos de este estilo de arquitectura son:

– Escalabilidad de la interacción con los componentes. La Web ha crecido exponencialmente sin degradar su rendimiento. Una prueba de ellos es la variedad de clientes que pueden acceder a través de la Web: estaciones de trabajo, sistemas industriales, dispositivos móviles…

– Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin ninguna configuración especial. Esto no es del todo cierto para otras alternativas, como SOAP para los Servicios Web.

– Puesta en funcionamiento independiente. Este hecho es una realidad que debe tratarse cuando se trabaja en Internet. Los clientes y servidores pueden ser puestos en funcionamiento durante años. Por tanto, los servidores antiguos deben ser capaces de entenderse con clientes actuales y viceversa. Diseñar un protocolo que permita este tipo de características resulta muy complicado. HTTP permite la extensibilidad mediante el uso de las cabeceras, a través de las URIs, gracias a la habilidad para crear nuevos métodos y tipos de contenido.

– Compatibilidad con componentes intermedios. Los más populares intermediarios son varios tipos de proxys para Web. Algunos de ellos, como las cachés, se utilizan para mejorar el rendimiento. Otros permiten reforzar las políticas de seguridad: firewalls. Y por último, otro tipo importante de intermediarios, gateway, permiten encapsular sistemas no propiamente Web. Por tanto, la compatibilidad con intermediarios nos permite reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.

Para poder conseguir estos objetivos, REST establece una serie de principios de diseño que se deben cumplir:


El primer principio es la identificación única de recursos. Los recursos se deben identificar y manipular a través de representaciones. Esto se consigue mediante el uso de URIs. HTTP es un protocolo centrado en URIs. Los recursos son los objetos lógicos a los que se le envían mensajes. Los recursos no pueden ser directamente accedidos o modificados. Más bien se trabaja con representaciones de ellos. Internamente el estado del recurso puede ser cualquier cosa, desde una base de datos relacional a un fichero de texto.

El segundo principio es el de interfaz uniforme, en el que todos los recursos deben compartir la misma interfaz uniforme formada por un conjunto de operaciones limitadas  para transferencia de estado (en HTTP GET, PUT, POST, DELETE) y por un conjunto limitado de tipos de contenidos (en HTTP se identifican mediante tipos MIME: XML, HTML,…)

El tercer principio es el de mensajes autodescriptivos. REST dicta que los mensajes HTTP deberían ser tan descriptivos como sea posible. Esto hace posible que los intermediarios interpreten los mensajes y ejecuten servicios en nombre del usuario. Uno de los modos de que HTTP logre esto es por medio del uso de varios métodos estándares, muchos encabezamientos y un mecanismo de direccionamiento. HTTP es un protocolo sin estado y, cuando se utiliza adecuadamente, es posible interpretar cada mensaje sin ningún conocimiento de los mensajes precedentes.

El cuarto principio es el de hipermedia como un mecanismo del estado de la aplicación, comúnmente conocido como HATEOAS (Hypermedia As The Engine Of Application State). Este principio dice que el estado actual de una aplicación web debería ser capturado en uno o más documentos de hipertexto, residiendo tanto en el cliente como en el servidor. El servidor conoce el estado de sus recursos, aunque no intenta mantener las sesiones individuales de los clientes. Esta es la misión del navegador, el sabe como navegar de recurso a recurso, recogiendo información que el necesita o cambiando el estado que el necesita cambiar. El formato de las representaciones debe estar documentado y ser estándar. Las representaciones deben incluir enlaces a otros recursos relacionados.

El quinto y último principio es el de comunicación sin estado (stateless). Según este principio no se debe establecer ninguna sesión entre el cliente y el servidor. El estado del cliente es gestionado por el cliente y el estado de los recursos es gestionado por el servidor. El servidor no guarda el estado de la comunicación.

Si un servicio web se ajusta a los principios de diseño de la arquitectura REST se dice que el servicio es RESTful. En el caso de que se viole cualquiera de las restricciones necesarias, ya no puede considerarse RESTful.

Ventajas que ofrece REST para el desarrollo:

  • Separación entre el cliente y el servidor: el protocolo REST separa totalmente la interfaz de usuario del servidor y el almacenamiento de datos. Eso tiene algunas ventajas cuando se hacen desarrollos. Por ejemplo, mejora la portabilidad de la interfaz a otro tipo de plataformas, aumenta la escalabilidad de los proyectos y permite que los distintos componentes de los desarrollos se puedan evolucionar de forma independiente.
  • Visibilidad, fiabilidad y escalabilidad. La separación entre cliente y servidor tiene una ventaja evidente y es que cualquier equipo de desarrollo puede escalar el producto sin excesivos problemas. Se puede migrar a otros servidores o realizar todo tipo de cambios en la base de datos, siempre y cuando los datos de cada una de las peticiones se envíen de forma correcta. Esta separación facilita tener en servidores distintos el front y el back y eso convierte a las aplicaciones en productos más flexibles a la hora de trabajar.
  • La API REST siempre es independiente del tipo de plataformas o lenguajes: la API REST siempre se adapta al tipo de sintaxis o plataformas con las que se estén trabajando, lo que ofrece una gran libertad a la hora de cambiar o probar nuevos entornos dentro del desarrollo. Con una API REST se pueden tener servidores PHP, Java, Python o Node.js. Lo único que es indispensable es que las respuestas a las peticiones se hagan siempre en el lenguaje de intercambio de información usado, normalmente XML o JSON.

En resumen, el creciente aumento del uso de servicios web REST se debe a la simplicidad y ligereza que ofrece este estilo arquitectónico. Si está interesado en aprovechar las ventajas (escalabilidad, generalidad de interfaces, desarrollo independiente de componentes y existencia de proxys) que han hecho que la Web tenga tanto éxito mediante un modelo de arquitectura, no dude en contactarnos.

Trackback URL: https://www.innova4j.com/apis-reset-escalabilidad-apps/trackback/

Dejar Comentario:

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *