Y llegamos a la última entrada de mi blog, esta vez prometo no hablar nada, pero nada de PeopleSoft ajajajajaja. Ahora les hablaré de REST y la disyuntiva que se presenta cuando creemos que estamos implementando RESTful y verdaderamente no es así. Ayer que estaba en la exposición final del proyecto de DSD el profesor me pidió una conclusión final acerca de mi proyecto; por esta razón, le comenté una solución que, para mi, era la mejor alternativa a un problema que quizás muchos de nosotros hemos tenido a lo largo del desarrollo de nuestros proyectos. El profesor, fiel a su estilo colaborativo, risueño y siempre con la precisa, me comentó que justamente eso que hice en mi proyecto permitía discernir si realmente estamos empleando REST o RESTful cuando nos enrumbamos a trabajar con métodos HTTP, Json, Fredys Kruger y demás ajajajaja.
Dejando a un lado las bromas, aprendí que la diferencia entre emplear REST y RESTful radica justamente en la últimas tres palabras que no tienen en común (ful). Esto significa que, aunque estemos trabajando con tramas Json y métodos HHTP al momento de implementar servicios, realmente no estamos aprovechando al 100% la funcionalidad REST. Específicamente, me refiero al hecho de emplear hipervínculos que nos permitan navegar de una clase a otra de modo que podamos aprovechar estructuras de otras clases estando en una clase que posee, digámoslo así, propiedades del tipo Foreign Key.
Pongamos un ejemplo, tengo la siguiente clase:
Podemos observar que, la clase Excepción tiene varias propiedades, algunas del tipo de datos clásico: int, DateTime y String y otras del tipo de datos clase: por ejemplo Usuario que es una extensión de la clase Usuario. Justamente aquí radica la razón de ser de esta entrada en mi blog. A la pregunta: ¿Como desarrollo la trama Json para poder insertar un nuevo registro de Excepción mediante REST?
Entonces me llevé con la sorpresa de que, al igual que WSDL, si deseo pasar la trama Json de esta clase debo considerar escribir no solo la estructura de la clase Excepción sino también, la estructura en árbol de la clase Usuario... como lo leen, la estructura completa de esta clase. Digamos que, la clase Usuario tiene 30 propiedades, estas mismas 30 propiedades deben ser escritas en la trama Json para registrar una Excepción común y corriente de 8 siemple campitos. Ahora bien, que sucede si dentro de la estructura de la clase Usuario tengo una situación similar a la de la clase Excepción; osea que, dicha clase cuente a su vez con propiedades que se extienden de otras clases (todo esto sin contar que la clase Usuario no es la única que aparece en la clase Excepcion). En conclusión, la trama Json que debemos escribir para poder registrar un a simple Excepcion se extendería de una manera trabajosa (por la cantidad de código que hay que digitar) y peligrosa (por la exposición innecesaria que haremos de otras clases al acceder a un solo recurso).
La solución, digamos muy utilizada por la mayoría de programadores el día de hoy pero no recomendada porque nos evita llegar al tan ansiado RESTful, que le dí a este problema fué la siguiente:
Espero haber contribuido un poco al conocimiento que posees sobre servicios REST.
Saludos
AAM
Podemos observar que, la clase Excepción tiene varias propiedades, algunas del tipo de datos clásico: int, DateTime y String y otras del tipo de datos clase: por ejemplo Usuario que es una extensión de la clase Usuario. Justamente aquí radica la razón de ser de esta entrada en mi blog. A la pregunta: ¿Como desarrollo la trama Json para poder insertar un nuevo registro de Excepción mediante REST?
Entonces me llevé con la sorpresa de que, al igual que WSDL, si deseo pasar la trama Json de esta clase debo considerar escribir no solo la estructura de la clase Excepción sino también, la estructura en árbol de la clase Usuario... como lo leen, la estructura completa de esta clase. Digamos que, la clase Usuario tiene 30 propiedades, estas mismas 30 propiedades deben ser escritas en la trama Json para registrar una Excepción común y corriente de 8 siemple campitos. Ahora bien, que sucede si dentro de la estructura de la clase Usuario tengo una situación similar a la de la clase Excepción; osea que, dicha clase cuente a su vez con propiedades que se extienden de otras clases (todo esto sin contar que la clase Usuario no es la única que aparece en la clase Excepcion). En conclusión, la trama Json que debemos escribir para poder registrar un a simple Excepcion se extendería de una manera trabajosa (por la cantidad de código que hay que digitar) y peligrosa (por la exposición innecesaria que haremos de otras clases al acceder a un solo recurso).
La solución, digamos muy utilizada por la mayoría de programadores el día de hoy pero no recomendada porque nos evita llegar al tan ansiado RESTful, que le dí a este problema fué la siguiente:
Entonces, para un servicio que iba a ser implementado mediante el estilio de arquitectura REST creé dos clases: una para inserciones (POST) y actualizaciones (PUT) y la otra para operaciones select (GET). Como vuelvo a repetir, esta no es una buena práctica cuando se trabaja con REST pero, es la que actualmente usan la mayoría de programadores. Por lo menos, para mi y para mi grupo de DSD fué la que nos sacó del gran problema de tener que escribir tramas Json complejas y muy anidadas.
Es justamente esta salida, o criollada muy típica de nosotros los peruanos, la que evita que podamos desarrollar una implementación RESTful y nos quedemos solo en REST. La pregunta sería entonces:
¿Como evitamos trabajar de esta forma?
Al igual que se puede serializar y deserializar propiedades tipo DateTime (Fecha) en cualquier Clase que creemos dentro nuestra carpeta Dominio (y esto de las fechas es un tema verdaderamente desgastado dado que, todos los ex alumnos de EPE ya lo han considerado en sus blogs), también podemos hacer lo mismo con propiedades que requieran obtener catálogos de otras clases (que a la larga se representan como un Foreign Key de Base de Datos).
Concusiones Finales
El objetivo de esta entrada no fué explicar paso a paso como lograr la serialización JSON; sino, identificar el problema existente, definirlo, poder sacarle la vuelta de una manera creativa, pero no recomendada (como la mayoría de programadores lo hacen actualmente) y fomentar la buena práctica de la implementación RESTful. Por esta razón, he encontrado un muy buen artículo en la web de Microsoft que nos introduce a la implementación de una buena práctica RESTful:
IMPORTANTE: Si a pesar de que luego de haberte explicado la manera correcta como deberías implementar tus servicios REST para llegar al "ful" decides continuar con la práctica que realicé en mi proyecto... toma en cuenta los siguientes consejos:
- La clase ExcepcionInsert solo debes utilizarla cuando realices Inserts (POST) y Updates (PUT).
- Si deseas realizar Selects (GET) de todo tipo, debes utilizar la clase Excepcion (la cual incluye la clase con sus propiedades originales) porque, te permitirá obtener las descripciones de todas las clases embebidas de una manera mas sencilla (de lo contrario, tendría que hacer un drill down de clases para obtener las descripciones que pretendes mostrar en tus páginas).
- Para mayor información puedes consultar esta implementación en el GoogleCode de mi proyecto (Grupo Innova): http://code.google.com/p/upc-epe-dsd-innova/source/browse/#svn%2Ftrunk%2FIncidenciasREST%253Fstate%253Dclosed
Espero haber contribuido un poco al conocimiento que posees sobre servicios REST.
Saludos
AAM
No hay comentarios:
Publicar un comentario