Arquitecturas RESTFul y agregados

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:

  1. Para acceder a todas las facturas usaremos el verbo GET y la URL /facturas
  2. Para acceder a una Factura usaremos el verbo GET y la URL /facturas/1 siendo 1 el identificador de la factura
  3. Para insertar una Factura volveremos a usar la URL de /facturas pero el verbo será POST
  4. Para borrar una Factura usaremos /facturas y el verbo DELETE
  5. 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.

  1. Para acceder a todas las lineas de Factura de una Factura concreta tendremos que usar /facturas/1/lineas
  2. 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

  1. Spring REST CORS y su configuración
  2. Single Page Application y REST
  3. Arquitecturas REST y sus niveles
  4. REST con Spring
Related Post