La estrella de Rails 1.2 - REST


#1

Despues de estar mirando un poco REST, aun no lo veo la importancia que
puede tener.
Leí que conseguiria reducir el codigo que escribiriamos, pero yo sigo
creando en mis controladores los tipicos “index o list”, “new”,
“update”,
“destroy”, etc (con mas codigo si cabe).
Ademas la implementacion que se hace en Rails, parece que solo funciona
si
tienes javascript activado, cosa que no me agrada demasiado (ya que los
navegadores no implementan por ejemplo el metodo DELETE).

¿Alguien puede explicarme cuando o como se consigue esa “revolucion
REST”?

Gracias.


#2

No lo he visto, pero bueno:

http://pablete.textdriven.com/screencast/


#3

yo sobre todo veo el potencial en las apis sustituyendo xml-rpc o
soap por http… es genial
recomiendo a la gente comprarse los screencast de peepcode, no son
caros y la velocidad de aprendizaje es tremeda

www.peepcode.com

El 23/01/2007, a las 18:05, Fernando B.
escribió:

No lo he visto, pero bueno:


#4

El 23/01/2007, a las 18:05, Fernando B.
escribió:

Ror-es mailing list
removed_email_address@domain.invalid
http://lists.simplelogica.net/mailman/listinfo/ror-es

En este screencast no se ve nada. Lo habia visto anteriormente, pero
es que lo unico que muestra es a hacer un scaffold_resource, cosa tan
simple poco ayuda, creo yo.

El 23/01/2007, a las 19:23, javier ramirez
escribió:>

que
drásticamente la complejidad del interfaz y la curva de "entendimiento
plumazo veo claramente qué se hace y a quién.
Ahora piensa también en que Rails (y tambien java 1.6 si nos ponemos a
Por cierto… sip, lo sé… estoy hipersimplificando alguna de las

saludos,

javier ramirez


Ror-es mailing list
removed_email_address@domain.invalid
http://lists.simplelogica.net/mailman/listinfo/ror-es

Pues si lo miras mas detenidamente, veras que que el campo hidden lo
crea “al vuelo”. Es decir, que no esta en la plantilla rhtml, sino
que cuando envias la peticion, crea un campo hidden con javascript
(almenos en mi codigo asi aparece).

En cuanto al planteamiento de recurso, pues yo no lo veo claro. En
una aplicacion rails 1.1 haciamos esto:

link_to “eliminar”, --> me lleva a por
ejemplo “productos/destroy/1” --> y esto se que va a ir al
controlador “productos” - accion “destroy”

esa era la practicidad con la que veia a rails. Se entendia
perfectamente, incluso para los que no habian visto rails en su vida

ahora dile tu a fulanito que mire el codigo:

link_to “eliminar”, --> me lleva
a … ¿destroy? --> porque? ande he puesto yo que vaya a ese metodo?

Yo aun me considero un novato en rails, por eso explico como veo yo a
REST. Me encantaria que me convencieran de su uso, pero es que por
ahora… como que no lo veo.
Quizas solo es practico cuando te encuentras cosas como SOAP.


#5

Ademas la implementacion que se hace en Rails, parece que solo
funciona si tienes javascript activado, cosa que no me agrada
demasiado (ya que los navegadores no implementan por ejemplo el metodo
DELETE).
Hablo de memoria, pero juraría que lo que hace rails es que cuando metes
un formulario indicando el nombre del modelo, para conseguir que tire
por REST lo que mete es un parámetro como hidden en el que indica el
tipo de operación CRUD con sus equivalentes POST,GET,PUT,DELETE.

Como bien dices, no todos los browsers soportan estos verbos HTTP, así
que rails se cura en salud y le mete un campo oculto que luego lee
cuando le llega la petición al controlador.

No veo el javascript por ninguna parte… un input type hidden es html de
toda la vida.

En cuanto a la utilidad de REST, bueno… para hacer sistemas
desacoplados/distribuídos es muy cómodo con muy poquito trabajo extra
(tanto en análisis, como en desarrollo como en implementación), así que
es toda una revolución frente a una solución SOA estándar.

Otra ventaja interesante es el enfoque… todo es un Recurso, y como tal
tiene una URI, de forma que si concateno mi_app/mi_tipo_de_recurso/mi_id
tengo perfectamente identificado cualquier item de mi sistema. Ahora
sobre este recurso el juego de operaciones que puedo hacer es el normal,
alta, baja, modificación y borrado. Sólo esas.Esto me permite reducir
drásticamente la complejidad del interfaz y la curva de “entendimiento
del interfaz”.

Si habéis trabajado con SOA, me da igual con COM,CORBA o SOAP, habréis
sufrido bonitos ficheros de definición de interfaces describiendo las
funciones disponibles y tratando de deducir que hacían. Aquí el enfoque
es diferente. Tengo cuatro operaciones, y tengo tantos modelos como
requiera para aplicarle estas operaciones.

Esto es mucho más sencillo de entender, con la ventaja de que de un
plumazo veo claramente qué se hace y a quién.

Si le añadimos que la entrada/salida es multicanal (multiformato) y en
función de la cabecera accepts puedes responder un tipo u otro de
respuesta, me parece muy interesante. A una URI tal que
“mi_app/mi_modelo/my_id” la podemos invocar bien mediante el browser
directamente o bien enviándole un xml o un yaml, por ejemplo. ¿Cuándo
fue la última vez que pudiste hacer una invocación a un servicio desde
tu browser? (Sin una aplicación por detrás que te convirtiera los datos?)

Ahora piensa también en que Rails (y tambien java 1.6 si nos ponemos a
ellos) tienen mapeo automático implícito de XML a objetos en memoria… o
sea, que me sale gratis convertir mi objeto a xml para enviarlo y
recibirlo, y como no necesito crear un envelope, me sale gratis
desacoplar mis interfaces (con el único coste de la invocación al
sistema remoto, que puede vivir en mi mismo servidor sin ir más lejos).

Suma todo esto junto, y empiezas a ver dónde está la gracia.

Por cierto… sip, lo sé… estoy hipersimplificando alguna de las cosas
que se pueden hacer, pero precisamente la idea de REST es quitarse de en
medio complejidad. Y, sí, es cierto, algunas cosas que se pueden hacer
mediante SOAP (u otros) todavía no tienen -y quizás no la tengan-
equivalente en REST. Pero es que realmente en muy poquitos casos he
visto que se usen cosas como el descubrimiento automático de servicios o
la asignación de roles a los diferentes agentes por los que pasa un
mensaje de punto a punto.

saludos,

javier ramirez


#6

El Martes, 23 de Enero de 2007 18:23, javier ramirez
escribió:

Hablo de memoria, pero juraría que lo que hace rails es que cuando metes
un formulario indicando el nombre del modelo, para conseguir que tire
por REST lo que mete es un parámetro como hidden en el que indica el
tipo de operación CRUD con sus equivalentes POST,GET,PUT,DELETE.

Como bien dices, no todos los browsers soportan estos verbos HTTP, así
que rails se cura en salud y le mete un campo oculto que luego lee
cuando le llega la petición al controlador.

No veo el javascript por ninguna parte… un input type hidden es html de
toda la vida.

Pues sí que lo hay. En el destroy hace uso de Javascript. No hace mucho
leí el
motivo, pero lo cierto es que no recuerdo ni la razón ni dónde lo leí :stuck_out_tongue:

drásticamente la complejidad del interfaz y la curva de “entendimiento
del interfaz”.

Para ello, hay que cambiar un poco la mentalidad y pensar en nuestra
aplicación como un puro CRUD (create, read, update y delete). Y es que la
mayoría de las típicas aplicaciones web pueden rediseñarse en estos términos.

Pensarás: vale, ¿y cómo hago, por poner un ejemplo, la típica
operación “cerrar incidencia”? Pues considerando el evento de “cerrado”
como
un modelo. Cuando cierras una incidencia, simplemente creas un objeto de
esta
clase (que puede tener asociada una incidencia, un usuario, etc.).

Heinemeier se explica mucho mejor que yo: te aconsejo que le eches un
vistazo
a su charla de la Railconf[1] apoyándote en sus respectivas
transparencias[2]. Está en inglés, pero vale la pena.

Si no puedes con el idioma, échale un vistazo a las transparencias y las
comentamos aquí mismo.

Un saludo.

[1] http://www.scribemedia.org/2006/07/09/dhh/
[2] http://www.loudthinking.com/arc/000593.html


Imobach González Sosa
imobachgs en banot punto net
osoh en jabberes punto org


#7

El Martes, 23 de Enero de 2007 20:51, javier ramirez
escribió:>

Y todo esto que parece tan natural se conecta al servicio via get para
guardar y vía put para el update.

limpio, no?

Yo de hecho he hecho alguna pequeña prueba y para una aplicación sencilla
tengo un cliente escrito en con Ruby y Qt que usa de forma transparente
la
interfaz REST gracias a ActiveResource.

Saludos.


Imobach González Sosa
banot.net
Correo-e: imobachgs en banot punto net


#8

Ah… se me olvidaba… lo que os comentaba antes era un uso de REST
aséptico en cuanto al lenguaje.

Lo que Rails aporta a REST es ActiveResource, que es un plugin que me
permite trabajar con recursos REST como si fueran ActiveRecord.

O sea, que puedo hacer
u=User.find(12)
u.name=‘javier’
u.save

Y todo esto que parece tan natural se conecta al servicio via get para
guardar y vía put para el update.

limpio, no?