Cuando hablamos de Arquitecturas RESTFul estamos haciendo referencia a un servicio que implementa los principios REST y nos publica un recurso en una url para que podamos acceder a él de forma sencilla. Crear un recurso REST es relativamente fácil ya que normalmente reservamos una URL y permitimos que se acceda a ella a través de los distintos verbos HTTP , vamos a ver un ejemplo utilizando el concepto de Factura.
A continuación se explican las diferentes opciones:
- Para acceder a todas las facturas usaremos el verbo GET y la URL /facturas
- Para acceder a una Factura usaremos el verbo GET y la URL /facturas/1 siendo 1 el identificador de la factura
- Para insertar una Factura volveremos a usar la URL de /facturas pero el verbo será POST
- Para borrar una Factura usaremos /facturas y el verbo DELETE
- Finalmente para actualizar una Factura usaremos /facturas y el verbo PUT
RESTFul y Agregados
Todo parece al principio muy sencillo pero en cuanto empecemos a construir una arquitectura REST un poco más compleja nos daremos cuenta que pronto surgen dudas . Una de las más habituales es como gestionar conceptos que están relacionados de forma agregada. Es decir cómo construir un conjunto de URLs que gestionen las LineasDeFactura . Esto en principio parece evidente simplemente es otro recurso mas . Lamentablemente las cosas no son tan sencillas ya que no puedo usar simplemente la URL /lineadefactura/1 . Ya que el 1 haría referencia al numero de linea , pero no sabría a qué factura pertenece.
Para solventar esto tenemos que recurrir a una estructura de agregados. En una estructura de agregados las Lineas de Factura dependen de la Factura.
- Para acceder a todas las lineas de Factura de una Factura concreta tendremos que usar /facturas/1/lineas
- Para acceder a una linea concreta tendremos que usar /facturas/1/lineas/2 de esta forma accederemos a la linea de Factura 2 de la Factura que tiene como identificador el 1.
Construir arquitecturas RESTFul siempre tiene su problemática ya que al basarse más en estilos que en patrones siempre hay muchas opciones a la hora de diseñarlo.
Otros artículos relacionados
Hola Cecilio,
como se descompondria tu ejemplo en microservicios rest hateoas.
No haría falta en principio ya que un microservicio , normalmente incluye ambos conceptos , muy especial tendría que ser para que uno tenga las facturas y otro las lineas. En ese caso las facturas tendrían que contener un link a las lineas
Te comento que el hateoas lo puedes cumplir siempre, así manejes solo las facturas, porque podrías retornar lo que puedes hacer después del Post por ejemplo, sería algo así
links”: {
“self”: {
“href”: “http://localhost:8080/facturas/1”
}
gracias por el aporte 🙂
primero los microservicios son un estilo de arquitectura, solo agregar los recursos a cada uno dependiendo de los dominios.