Tabla de contenidos
¿ Que es REST ? Esta pregunta es una de las más habituales en nuestros días. Para algunas personas REST es una arquitectura , para otras es un patrón de diseño , para otras un API. ¿Que es REST exactamente? . REST o Representational State Transfer es un ESTILO de Arquitectura a la hora de realizar una comunicación entre cliente y servidor.
Vamos a intentar explicarlo esto paso a paso . Habitualmente cuando nosotros realizamos una comunicación cliente servidor accedemos al servidor en un punto de acceso , le enviamos una información y recibimos un resultado.
Ahora bien hay muchas formas de realizar esta operación .¿Cual es la más correcta? . Esa es una buena pregunta. Hoy por hoy una de las necesidades más claras es que esa comunicación sea abierta y podemos acceder desde cualquier sitio. Asi pues estamos hablando de una comunicación HTTP (Hyper Text Transfer Protocol) . Usamos el puerto 80 de nuestro servidor para permitir el acceso a la información desde cualquier lugar.
Una vez tenemos claro el protocolo de comunicación el siguiente paso es decidir que tipología de mensajes enviamos. Como punto de partida podemos mandar a un servicio un mensaje en formato XML o JSON. El servicio lo recepcionará y nos devolverá una respuesta. Hoy por hoy es mucho más habitual usar JSON que XML. ¿Porque? pues porque muchos de los clientes que se utilizan son capaces de procesar JavaScript de una forma muy nativa. JSON recordemos que es el acrónimo de JavaScript Object Notation.
Esta situacion es lo que habitualmente en Arquitecturas REST se denomina el nivel 0. No tenemos ningún tipo de organización es caótico pero accedemos a la información en formato de dato puro.
¿ Que es REST ? (Nivel 1 Recursos)
El siguiente paso es lo que se denomina nivel 1 , en vez de tener servicios con métodos diversos declaramos Recursos.
El concepto de Recurso REST
¿Qué es un Recurso? . Un recurso hace referencia a un concepto importante de nuestro negocio (Facturas ,Cursos , Compras etc). Es lo que habitualmente se denomina un objeto de negocio.
Este estilo permite un primer nivel de organización permitiendo acceder a cada uno de los recursos de forma independiente, favoreciendo la reutilización , aumentando la flexibilidad y abordando operaciones de inserción ,borrado , búsqueda etc. Estamos definiendo los conceptos que vamos a compartir entre Cliente y Servidor.
¿ Que es REST ? (Nivel 2 HTTP Verbs)
Hasta este momento para realizar las peticiones y enviar datos se usan GET o POST indistintamente . En el nivel 2 las operaciones pasan a ser categorizadas de forma más estricta. Dependiendo de cada tipo de operación se utilizará un método diferente de envío.
- GET: Se usara para solicitar consultar a los recursos
- POST: Se usará para insertar nuevos recursos
- PUT : Se usará para actualizar recursos
- DELETE : Se usará para borrar recursos
Este es el nivel en el que hoy en día se encuentran muchas de las Arquitecturas REST y que nos encontraremos en muchas aplicaciones.
HATEOAS (Nivel 3)
Todavía nos queda un nivel más que es el que se denomina HATEOAS (Hypertext As The Engine Of Application State). ¿Para qué sirve este nivel?. Supongamos que queremos acceder a un recurso Alumno via REST . Si tenemos una Arquitectura a nivel 2 primero accederemos a ese recurso utilizando GET. En segundo lugar deberemos acceder al recurso de Cursos para añadir al alumno al curso (linea roja) .
Esto implica que el cliente que accede a los servicios REST asume un acoplamiento muy alto, debe conocer la url del Alumno y la del Curso. Sin embargo si el recurso del Alumno contiene un link al recurso de Curso esto no hará falta y desde la url de Alumno directamente podremos acceder a la url del curso que pertenece a ese alumno.
Podríamos tener una estructura JSON como la siguiente:
{nombre:”pedro”, apellidos:”gomez”, cursos:”http://miurl/cursos”}
Podremos acceder directamente al recurso de Curso utilizando las propiedades del Alumno esto es HATEOAS. De esta forma se aumenta la flexibilidad y se reduce el acoplamiento. Construir arquitecturas sobre estilo REST no es sencillo y hay que ir paso a paso. Mi recomendación es que empecemos a abordarlas en un nivel 2 para más adelante si las necesidades surgen abordar un nivel 3 .
He leído varios artículos sobre el tema y de hecho estoy comenzando a desarrollar, este artículo realmente da una visión general muy esclarecedora sobre REST. Muchas gracias.
gracias 🙂
Muy Interesante 🙂
Tambien me ayudo a entender el concepto de REST. Muchas Gracias!!
de alegro 🙂
Me has ayudado a entender el concepto. Gracias!
de nada 🙂
Hola, me podrías por favor decir la referencia bibliográfica(en ingles o español) de donde te basastes para este interesante blog?
Felicitaciones por la página, muy buenos artículos!
gracias 🙂
Me podrías enlazar al siguiente paso? o tal vez podrías compartir información de este tipo de servicios desde un inicio. Gracias!
Busca en mi blog hay varios articulos sobre la tecnologia
Saludos desde Republica Dominicana.
tenia rato tratando de entender este concepto el cual me ha quedado muy claro, la manera en que lo expone con imagenes lo hace ver mucho mas claro.
gracias 🙂
Sencillo y muy claro !
Faltan las comillas en el nombre (“pedro”) del json.
Saludos
corregido gracias 🙂
Sencillo y clarisimo!!! Me ahorraste horas de lectura…se agradece.
Lo que queda ahora es profundizar y experimentar!!!
de nada 🙂
Muy buena data! estoy encarando una app en Ionic y el tema persistencia de datos me preocupa un poco. Me gustaria que me digan si utilizar servicios rest en java me va a permitir un buen funcionamiento de la app, y un ida y vuelta de info de forma fluida. Gracias!
Si salvo que la estructura de datos sea muy compleja y realices n peticiones asíncronas
Tus artículos geniales como siempre.
Offtopic: No me gusta el look&feel que tiene el sitio actualmente jeje XD
Todo no se puede tener nelson 🙂 ahora la web carga en 0.4 segundos lo cual esta bastante bien el tema es genesis con un childtheme normalito.
Muy buen articulo, gracias
de nada 🙂
Excelente, algo importante también en REST y creo que en cualquier estilo de arquitectura, es siempre paginar la información, por ahora estoy tratando de implementar HATEOAS y con los Spring Repository va bien el problema es cuando quiero integrar lucen y no se si es mejor utilizar Hibernate Search (que conozco su funcionamiento) o Elastic Search, igual un articulo sobre estos 2 estaria bien
Y que ventajas tiene sobre el httpRequest? O sobre ejb?
Nos permite generar aplicaciones más abiertas , a ver si saco un rato y escribo sobre este tema 🙂