lunes, junio 05, 2006

Traducción de Artículo de Ajax XVIII

Tipos de peticiones adicionales
Si realmente quieres tener el control del objeto XMLHttpRequest, considera este última parada -- agregar peticiones HEAD a tu repertorio. En los dos artículos previos, te mostré como hacer peticiones GET, en un próximo artículo, vas a aprender todo sobre mandar información al servidor usando las peticiones POST. Con el espíritu de realzar la gestión de errores y la reunión de información, debes aprender como hacer peticiones HEAD.
Hacer la Petición
Realmente hacer una petición HEAD es absolutamente trivial. Simplemente llama al método open() con HEAD en vez de GET o POST como primer parámetro, como de muestra en el listing 9.
Listing 9. Hacer una petición HEAD con Ajax

function getSalesData(){
createRequest();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

Cuando haces una petición HEAD como esta, el servidor no devuelve una respuesta real como lo haría para una petición GET o POST. En su lugar, el servidor solo tiene que devolver las cabeceras de la fuente que incluye la ultima hora que el contenido de la respuesta fue modificado, si la fuente de la petición existe o no, y algunas otras partes interesantes de información. Podés usar varias de esas para descubrir sobre un recurso antes que el servidor haya procesado y devuelto ese recurso.
La cosa mas fácil que puedes hacer con una petición como esta es simplemente mostrar todas las cabeceras de la respuesta. Esto te da la pauta de que es lo que tenes disponible a travez de las peticiones HEAD. El listing 10 provee una funcion de rellamada simple para exteriorizar todas las cabeceras de respuesta de una peticion HEAD.
Listing 10. Imprimir todas las cabeceras de respuesta de una petición HEAD

function updatepage(){
if (request.readyState == 4){
alert(request.getAllResponseHeader());
}
}

Controlar la figura 7, que muestra las cabeceras de respuestas de una aplicación simple que hace peticiones HEAD a un servidor.
Figura 7. Cabeceras de respuesta de una petición HEAD
Podés usar cualquiera de esas cabeceras (desde el tipo de servidor hasta el tipo de contenido) individualmente para dar información extra o funcionalidad dentro de una aplicación Ajax.
Controlar una URL
Ya has visto como controlar un error 404 cuando una URL no existe. Si esto se vuelve un problema comun --probablemente algún script o servlet este fuera de lineo cada tanto-- podrías querer controlar la URL antes de hacer una petición GET o POST completa. Para esto, haz una petición HEAD y luego controla el error 404 en tu funcion de rellamada; El listing 11 muestra una rellamada de muestra.
Listing 11. controlar si una URL existe

function updatePage(){
if (request.readyState ==4){
if (request.status==200){
alert ("Existe URL");
} else if (request.status ==404){
alert ("No existe la URL");
} else{
alert ("El estado es: " + request.status);
}
}
}

Para ser honestos, esto tiene poco valor. El servidor tiene que reponder la petición y resolver una respuesta para poblar el tamaño del contenido de la cabecera de respuesta, entonces no salvas nada de tiempo de procesamiento. Además, toma tanto tiempo hacer la petición y ver si la URL existe usando un petición HEAD que si lo hicieras usando GET o POST, solo estionando los errores como se muestra en el Listing 7. Aún así, a veces es útil saber exactamente que está disponible; nunca sabes cuando surgirá la creatividad y necesites la petición HEAD.
Peticiones HEAD útiles
Un área donde vas a encontrar útil la petición HEAD es para controlar el tamaño del contenido o también el tipo del contenido. Esto te permite determinar si tal cantidad de información va a ser devuelta para procesar la petición o si el servidor va a tratar de devolver información binaria en vez de HTML, texto o XML (los cuales son mucho mas fácil de procesar por JavaScript que la información binaria).
En esos casos, usas la cabecera apropiada y lo pasas al método getResponseHeader() del objeto XMLHttpRequest. Entonces para obtener el tamaño de una respuesta, solo llama al request.getResponseHeader("Content-Length");. Para obtener el tipo del contenido, usa request.getResponseHeader("Content-Type");.
En muchas aplicaciones, hacer peticiones HEAD no agrega funcionalidad y hasta poner lenta una petición (forzando una petición HEAD para obtener información sobre la respuesta y luego la petición GET o POST para obtener la respuesta propiamente dicha). Sin embargo, en el caso de que no estes seguro sobre un script o un componente del lado servidor, una petición HEAD puede permitirte obtener alguna información básica sin tener que lidiar con información de respuesta ni necesitas el ancho de banda para enviar esa respuesta.
En Conclusión
Para muchos programadores de Ajax y Web, el material en este artículo puede parecer bastante avanzado. ¿Cual es el valor de hacer una petición HEAD?¿Cual es realmente el caso donde deberías gestionar un codigo de estado de redireccionamiento explicito en tu JavaScript? Son buenas preguntas; para aplicaciones simples, la respuesta es que esas tecnicas avazadas probablemente no sean validas.
Sin embargo, la Web no es mas un lugar donde solo son toleradas aplicaciones simples; usuarios han vuelto más avanzados, los clientes esperan robustez y reportes de errores avanzados, y los directores son despedidos porque una aplicacion se cae un 1% del tiempo.
Es tu trabajo entonces, ir más allá de una simple aplicación y eso requiere una comprensión más profunda de XMLHttpRequest.
  • Si puedes explicar la variedad de estados ready --y comprender como se diferencian de navegador a navegador -- serás capas de eliminar errores de una aplicación rápidamente. Puede ser que incluso aparezcas con una creativa funcionalidad basada en los estados Ready y reportes un estado de la petcion a los usuarios y clientes.
  • Si tiene un manejo de los códigos de estados, podes fijar tu aplicación para que maneje los errores en el script, las respuestas inesperadas y los casos límite. Como resultado, tu aplicación va a trabajar todo el tiempo, mas que solo en llas situaciones en que todo está bien.
  • Agregas a hesta habilidad el hacer peticiones HEAD, controlar la existencia de una URL, y descubrir cuando un archivo fue modificado y puede asegurar que los usuarios acceden a páginas validas, estan actualizados en su información y (lo más importante) los sorprendes con solo lo robusta y versatil que es tu aplicación.
Este artículo no va a hacer tus aplicaciones llamativas, ayudarte a resaltar el texto con luces amarillas que se devanecen, o que se sientan más como un escritorio. Mientras estas son todas fortalezas de Ajax (y temas que trataremos en próximos artículos) son en algun grado solo beneficios adicionales. Si podés usar Ajax para construir una sólido base en la cual tu aplicación maneje los errores y problemas suavemente, los usuarios van a volver a tu sitio y aplicación. Agregale a esto los trucos visuales de los que vamos a hablar en próximos artículos y vas a tener clientes emosionados, entusiasmandos y felices. (seriamente, no querrás perderte el próximo artículo!)

Etiquetas: