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
