[Ror-es] REST y campos ocultos

[Listas de Correo]

Podrían indicar de que libro están hablando?

Gracias.

Xavier Noria escribió:
> On Nov 24, 2007, at 11:19 PM, Juan Quemada wrote:
>
> Hola Juan,
>
>   
>> Gracias por los comentarios, porque el concepto
>> de stateless no es facil de explicar.
>>     
>
> Estoy de acuerdo. El libro de O'Reilly (400+ paginas de primera  
> calidad, desde luego que subscribo la recomendacion de Juan y Joaquin)  
> me ha ayudado muchisimo a cuadrar las cosas ya que te explica los  
> fundamentos. Una vez entiendes los fundamentos lo demas se sigue. Y  
> aun y asi implementamos en ASPgems un servicio web puro REST *muy pero  
> que muy sencillo* (una pasarela de reservas de hoteles), nos  
> esforzamos en que fuera canonicamente REST, y surgieron algunas dudas  
> que en rest-discuss me ayudaron a resolver. En vuestra charla  
> observasteis algo que comparto del todo por mi experiencia, las reglas  
> de juego son sencillas, pero hacer el modelo basado solo en recursos  
> puede costar hasta que no lo tengas por la mano.
>
> Y aun en mi caso estoy acostumbrado a hacer web sin estado, por eso  
> apoyo el cambio a cookie-based sessions por defecto en la 2.0 (hay un  
> thread en -core), porque en mis sesiones solo hay un user_id y  
> eventualmente un flash. Nada mas. Lo que me ha costado es pensar  
> estrictamente en recursos, interfaz unica, y codigos HTTP. Quien este  
> acostumbrado a tirar de sesion en web tiene aun mas que batallar.
>
> Es un paradigma distinto, y cuesta hasta que no aprendes a pensar con  
> esas reglas (como en cualquier cambio de paradigma). Asi que pienso  
> como vosotros que el curso que preparais tiene un reto pedagogico  
> importante.
>
>   
>> Cuando hablas de la transacción bancaria me
>> da la impresion que es la tipica transacción
>> con varias operaciones que no se pueden
>> consolidar hasta que se finaliza la secuencia
>> y se realiza el commit o el rollback, que también
>> es un truco para implementar transacciones
>> multioperación en un entorno REST.
>>     
>
> Exacto. De hecho honestamente creo que eso es un medio cambalache,  
> porque estas como disfrazando estado con un recurso. En una operacion  
> donde debes quitar de aqui y poner alli atomicamente pero usando  
> distintas peticiones, estas estan vinculados. No hay tu tia. Tal como  
> se propone en el libro si la transaccion ni la comitea (heh :-), ni la  
> borra, se queda ahi de basura. Ya que ellos proponen en esa tecnica  
> (hay mas) que el recurso transaccion tenga como estado lo que debe  
> hacer, para ejecutarlo en commit, borrarlo si rollback, y para que  
> mientras la transaccion esta abierta el resto de la aplicacion vea los  
> objetos afectados como estan "fuera" de la transaccion.
>
> Eso a mi modo de ver es casi casi una sesion con el nombre cambiado.  
> Te lo puedes mirar como un recurso si, peroooo, tengo mixed-feelings  
> la verdad.
>
> Lo REST seria que pudieras decir en una _sola_ request todo lo que  
> necesites que sea atomico. Ahi bien. Si tu aplicacion necesariamente  
> tiene peticiones separadas y vinculadas y no son una excepcion podria  
> pasar que REST no sea lo mas adecuado en mi opinion, habria que ver.  
> Si la aplicacion puede ser stateless perfecto, si no puede ser  
> stateless creo que lo apropiado es aplicar otro paradigma.
>
> No en vano en el libro dedican bastante a hablar de transacciones,  
> creo que es porque esta ahi en la frontera y es un ejercicio dificil  
> encajarlas en las premisas REST.
>
> Si pudiera humildemente aportar algo al curso de la forma que fuere  
> desde luego que podeis contar conmigo.
>
> -- fxn
>
> _______________________________________________
> Ror-es mailing list
> Ror-es at lists.simplelogica.net
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>