[l-desarrollo] REST y las Relaciones de bases de datos
Daniel Peraza
aclarar algunos conceptos de la arquitectua REST. Conozco bien que la
arquitectura se basa en acceder mediante verbos HTTP a recursos en una
red. Sin embargo, en la práctica los recursos tienen relación entre sí.
Por ejemplo, una factura contiene un listado de renglones. La pregunta
es: ¿Si ejecuto una operación GET sobre /facturas/, debo retornar
también los renglones que contiene?
Pregunto porque pareciera obvio que la forma correcta de acceder a los
renglones sería algo como GET /facturas/1234/renglones/, pero esto
implicaría un overhead adicional para una aplicación al tener que
ejecutar una segunda petición para obtener los recursos relacionados.
_______________________________________________
l-desarrollo mailing list
l-desa...@velug.org.ve
http://listas.velug.org.ve/mailman/listinfo/l-desarrollo
José Manuel Peña
> aclarar algunos conceptos de la arquitectua REST. Conozco bien que la
> arquitectura se basa en acceder mediante verbos HTTP a recursos en una red.
> Sin embargo, en la práctica los recursos tienen relación entre sí. Por
> ejemplo, una factura contiene un listado de renglones. La pregunta es: ¿Si
> ejecuto una operación GET sobre /facturas/, debo retornar también los
> renglones que contiene?
de Datos. Si partes de un modelo relacional normalizado entonces es
mas fácil generar una interfaz REST cuya estructura/diseño mapee 1:1
con el modelo relacional que has definido.
>
> Pregunto porque pareciera obvio que la forma correcta de acceder a los
> renglones sería algo como GET /facturas/1234/renglones/, pero esto
> implicaría un overhead adicional para una aplicación al tener que ejecutar
> una segunda petición para obtener los recursos relacionados.
recursos internamente. Esto no supone problema alguno, salvo en casos
muy atípicos.
Saludos,
José Manuel Peña P.
Daniel Peraza
En efecto la base de datos es relacional y normalizada hasta la 3ra forma normal, lo usual para aplicaciones de bases de datos.
No obstante, segun lo que comentas, supongo entonces que para obtener un resumen de una entidad con algunos atributos de sus relaciones (por ejemplo 1:N), deberia pensar en un nuevo recurso?
Manuel Chouza
lo que entiendo de tu pregunta no tiene nada que ver con la base de datos.
una cosa es como tenes modelado tus estructuras de negocios en este caso tus tablas u objetos de dominio.
por el otro relacionado al el overhead que mencionaste tiene que ver con la estrategia que usas para transformar esa estructura de respuesta sean objetos o tablas en la respuesta final de esa method request.
a modo hipotético dado que no se mucho la arquitectura de tu sistema, digamos que si tus objetos están definidos por anotaciones lo que significa que si pedís una factura por defecto si la factura contiene referencia a sus items debería retornar también sus items por defecto.
ahora es ahí donde vos decidís que estrategia querés usar en la conversión de esos objetos que tenes almacenados en tablas de base de datos dependiendo de si retornas XML o binario o json o lo que fuere.
pensá que para que vos finalmente obtengas la respuesta que querés existe una conversión/mapeo , magia por si sola no se aplica.
y por otro lado si tu modelo esta relacionado en DB, tu método de DAO puede o no recuperar los items, eso lo codeas pragmáticamente si no usas hibernate o algo que se le parezca.
espero te sirva de ayuda la respuesta.
Saludos
Manuel.
Ricardo Correa
> Saludos amigos. Quisiera por favor me prestaran un poco de ayuda para
> aclarar algunos conceptos de la arquitectua REST. Conozco bien que la
> arquitectura se basa en acceder mediante verbos HTTP a recursos en una red.
> Sin embargo, en la práctica los recursos tienen relación entre sí. Por
> ejemplo, una factura contiene un listado de renglones. La pregunta es: ¿Si
> ejecuto una operación GET sobre /facturas/, debo retornar también los
> renglones que contiene?
>
Realmente no hay "debo"s refiriéndose a REST, porque no hay un
estándar de como hacer las cosas.
> Pregunto porque pareciera obvio que la forma correcta de acceder a los
> renglones sería algo como GET /facturas/1234/renglones/, pero esto
> implicaría un overhead adicional para una aplicación al tener que ejecutar
> una segunda petición para obtener los recursos relacionados.
Te recomiendo leer este blog post [1]. Ellos resuelven este problema
de una forma que me parece justa, en el párrafo titulado "The RedRata
vendor specific Accept types".
Su solución consiste en utilizar los headers de HTTP, en específico el
"Accept Header", para darle al cliente la posibilidad de definir la
representación del recurso, y si desea simplemente el recurso en
cuestión o todo lo que hay por debajo. Esto lo hacen con headers de
tipo "{type}/vnd.{company}{type}+{subtype}", como por ejemplo
"application/vnd.redrata.deep+json" o
"application/vnd.redrata.shallow+json". La parte relevante aquí es el
parámetro deep/shallow, que sin complicarse mucho se traduce a
profundo o plano.
Como ellos debaten un par de párrafos mas arriba, es tentativo hacer
esto en la URI, pero esta debería estar reservada a ocuparnos del
recurso y no de su representación, por lo que a mi parecer, a menos
que se te dificulte demasiado trabajar a nivel del Request, deberías
tomar en cuenta su solución.
P.D.: A mi si me parece que es al menos relevante hablar de la Base de
Datos, ya que no todo está limitado a la visión de las RDBMs (aunque
ya Daniel haya aclarado que usa una). Por ejemplo, en las orientadas a
documentos puedes guardar todo un recurso y sus "hijos" y luego
recuperarlos todos juntos, o por ejemplo en Riak se usa esta técnica:
[2].
1. http://redrata.com/restful-uri-design/
2. http://wiki.basho.com/Links-and-Link-Walking.html