JASoft.org

El blog de José Manuel Alarcón Aguín. Programación web y mucho más...

MENÚ - JASoft: JM Alarcón

AJAX (VI): Posibles problemas (III) - Envío de información grande

En esta tercera parte (sexta de la serie) dedicada a los problemas/desafíos relacionados con AJAX vamos a tratar el envío de datos al servidor.

Normalmente cuando pensamos en AJAX, es decir, en llamadas asíncronas a servicios, lo hacemos desde el punto de vista de obtener información: llamo a una página que me devuelve unos valores y los muestro en la interfaz de usuario. Aunque este es el uso más común de AJAX lo cierto es que también es muy útil usarlo en el sentido inverso, para enviar datos al servidor. Las utilidades y necesidades que cubre son múltiples y de hecho hay muchos sistemas. Por ejemplo, las plataformas de teleformación como nuestro SELF, lo usan para la parte de comunicación entre contenidos y plataforma de la especificación SCORM.

la forma más sencilla y directa de enviar datos simples al servidor es incluirlos en la URL a la que llamamos como parámetros GET:

urldestino.aspx?Parametro1=1234&Parametro2=5

Aunque esto puede servirnos para cosas muy sencillas no es a lo que me refería al principio de este post.

Lo habitual es que la información haya que enviarla con el método POST. La principal diferencia entre GET y POST estriba en que el método GET hace una llamada al servidor solicitando una página y enviando algunos parámetros de datos en la propia petición. El método POST por el contrario envía los datos en el cuerpo de la propia conexión de petición encriptados con el formato que se haya indicado en el formulario. A través de GET lo máximo que se puede enviar son 2 kB de información, mientras que por POST no existe esta limitación.

Para enviar datos al servidor mediante POST nuestro código AJAX sería similar al siguiente:

http = getHttpRequest()
http.onreadystatechange = finCarga;
http.open("POST", "http://www.miserv.com/misdatos.aspx", true)
http.send('Parametro1=1234&Parametro2=5');

Con esto no hemos ganado demasiado. Ahora se envían  los datos por POST (sólo cambia elprimer parámetro de open) pero los hemos tenido que introducir en el método send en lugar de en la propia URL. Esto sólo simularía el envío de parámetros meidante POST desde un formulario HTML (que por otro lado en ocasiones puede ser lo que queramos).

Lo habitual sin embargo es que en lugar de enviar parámetros querramoe enviar información pura y dura, del tamaño que queramos, que es para lo que suele usarse POST. Esto se puede conseguir modificando ligeramente el código anterior para incluir una cabecera que indique al servidor que lo que le llega son, precisamente, datos:

http = getHttpRequest()
http.onreadystatechange = finCarga;
http.setRequestHeader('content-type', 'application/x-www-form-urlencoded');
http.open("POST", "http://www.miserv.com/misdatos.aspx", true)
http.send('Aquí ahora mando la información que quiera al servidor');

Con esto nuestro problema queda resuelto.

José Manuel Alarcón José Manuel Alarcón
Fundador y director de campusMVP.es, el proyecto de referencia en formación on-line para programadores en lengua española. Autor de varios libros y cientos de artículos. Galardonado como MVP de Microsoft desde 2004. Gallego de Vigo, amante de la ciencia y la tecnología, la música y la lectura. Ayudando a la gente en Internet desde 1996.
Mi último libro (no técnico): "Tres Monos, Diez Minutos".
Banner

Comentarios (6) -

Buenas Jose,

primero de todo quiero felicitarte por tu vuelta a "la arena", se te ha echado de menos por estas lares ;)

Al tema, hace tiempo que desarrollo con Ajax, de hecho, cuando oí por primera vez el término, hacía como un año que desarrollaba usando el componente HttpRequest.

Debido al momento en que empecé a desarrollar usando estas técnicas, me acostumbré a trabajar "a pelo" con dicho componente, en aquellos momentos no existía (o yo no conocía) ni Sarissa (http://sarissa.sourceforge.net/doc/), ni Dojo (http://dojotoolkit.org/), prototype (http://prototype.conio.net/), Atlas (http://atlas.asp.net/) ni nada por el estilo.

El caso esque yo siempre trabajo con una página html (sí, es estática o "casi") y via Ajax no solo pido información, si no que tambien la envío. He eliminado el concepto de hacer un submit de un formulario, simpre tengo un documento xml en memoria en el cliente con los datos, y via js sincronizo html y xml (en los dos sentidos). Cuando quiero guardar los cambios hago un post de todo el documento xml y lo proceso en el servidor. Esto es muy sencillo de hacer, basta pasar la instancia del documento xml al metodo send que tú has comentado, en el cuerpo de la petición nos llegará el xml al servidor.

Es evidente que de esta manera la comunicación és muuuucho más rica al ser xml mucho más flexible y estandar que otras codificaciones. Lo que me sorprende es que ninguno de los frameworks excepto Sarissa (desconozco el caso de Atlas porque no curro en .Net) permite pasárle nada al send del HttpRequest. Encapsulan tanto su funcionamiento que resulta imposible obtener una referencia a él. Y Sarissa no es bien bien un framework, sencillamente hacen más sencillo el trabajo cross browser, pero no aportan la potencia de los otros.

En fin, vaya rollo te he metido, todo para decir que no puedo entender cómo comunidades tan activas como estas no se hayan dado cuenta de que estan desperdiciando, como mínimo, la mitad de la potencia de Ajax. ¿Será que son proyectos aún demasiado jóvenes? ¿Soy yo que me dejo algo?

Responder

Hola Marto:

Gracias por los comentarios :-)

Como comento en el POST, la mayor parte de los programadores cuando piensan en AJAX lo hacen sólo en un sentido, es decir, en el de recibir datos del servidor pero muy pocos lo utilizan para enviarlos, lo cual es muy potente y en ocasiones verdaderamente útil.

En el caso de ATLAS no se trata únicamente de una ayudita para manejar AJAX: es un verdadero framework de desarrollo que te permite conectarte y usar directamente desde el cliente Servicios Web (y por lo tanto recibir y enviar datos con éstos).

Además hay una cuestión muy importante sobre Atlas que mucha gente desconoce: es independiente de la tecnología del servidor. Es decir que aunque está preparado para trabajar codo con codo con ASP.NET y es cuando realmente le sacaremos partido, lo cierto es que toda la parte de cliente la podemos utilizar sin problemas con otras tecnologías de servidor como PHP, JSP, etc...

Yo creo que Atlas está mucho mejor que lo que hay ahora mismo por ahí, y me fastidia decirlo porque parece que todo lo que hace Microsoft lo pongo por las nubes, pero es que realmente lo merecen en la mayor parte de los casos... ;-)

Por cierto, he visto que has actualizado mi RSS en tu sitio. Gracias. Por favor, usa mejor el RSS de www.jasoft.org y no el de Geeks.ms, ya que ese es un "mirror" de este (el principal es este) y no sale todo lo que se publica aquí (todo lo antiguo, por ejemplo).

Un saludo

Jose.

Responder

Buenas de nuevo,

le echaré un ojo a Atlas, lo cierto es que pensaba que iba ligado a .Net (como dwr http://getahead.ltd.uk/dwr/ lo está a java). De todas maneras, de las suites que comenté antes, la única que es una "simple ayudita" es Sarissa, el resto van bastante más allá.

Ah! a ver si este fin desemana actualizo el enlace al rss :)

Responder

No, en AJAX es en ese orden...

Saludos

JM.

Responder

Uruguay Juan Gómez

Hola José,
Antes que nada felicitaciones por tus articulos la verdad son muy claros y me han sido de gran ayuda.
Te quería hacer una pregunta sobre algo que mencionas ya que no encontre respuesta a mi duda en ningun otro lado.
Por qué decis que "POST por el contrario realiza dos conexiones al servidor. en la primera solicita una URL y en la segunda envía los datos"?
Es decir, no me doy cuenta como se puede realizar un mismo POST en dos conexiones distintas ya que HTTP al no tener estado no tiene forma distinguir conexiones.

Saludos y Gracias,
Juan

Responder

Spain José Manuel Alarcón

Hola Juan,

Tienes razón, eso no está bien explicado. En realidad una petición POST se realiza con una sola conexión pero los datos se envían dentro del cuerpo de ésta, no en la propia URL.

Lo corregiré (esto es muy viejo y ya le toca una revisión).

Saludos,

Responder

Agregar comentario