Traducción de Artículo de Ajax XVII

Redireccionamientos y reenrutamiento
Antes de hablar en profundidad sobre errores, vale la pena hablar sobre algo que probablemente no hay que preocuparse cuando estas usando Ajax -- redireccionamientos. En los códigos de estado de HTTP, esta es la familia 300 de los códigos de estado, incluyendo:

• 301: Movido permanentemente
  
• 302: Encontrado (La petición fue redireccionada a otra URL/URI)
• 305: Usar Proxy (La petición debe usar proxy para acceder al recurso solicitado)

los programadores de Ajax probablemente no están preocupados por los redireccionamientos por dos razones:

• Primero, las aplicaciones ajax siempre se escriben para un script, servlet o aplicación del lado-servidor especifico. Para que ese componente desaparesca y sea movido a otro lado sin que vos, el programador de ajax, te enteres es un poco extraño. Entonces, más a menudo que no, vas a saber que ese recurso fue movido (por que lo moviste), cambias la url en tu petición y nunca te encuentras con este tipo de resultados.
• y la razon las relevante es: Las aplicaciones Ajax tiene sandbox. esto significa que el dominio que sirve a una página Web que hace peticiones Ajax es el dominio que tiene que responder a esas peticiones. Por esto una pagina web servida por ebay.com no puede hacer una peticion de estilo Ajax a un script que se ejecuta en amazon.com; Aplicaciones Ajax en ibm.com no pueden peitcionar a los servlets que se ejecutan en netbeans.org

Como resultado, tus peticiones no pueden ser redirecciondas a otro servidor sin generar un error de seguridad. En esos casos, no vas a recibir un código de estado. Normalmente solo vas a tener un error JavaScript en la consola de debug. Por esto, mientras que piensas en un montón de códigos de estado, puedes ignorar en gran parte los códigos de redireccionamiento en conjunto.

Casos límite y casos difíciles
En este punto, los programadores principiantes se preguntaran qué es todo este lio. Es cierto que menos del 5% de las peticiones Ajax requieren trabajar con los estados ready 2 y 3 y los códigos de estados como el 403 (de hecho, sería más cercano al 1% o menos). Estos casos son importantes y se llaman casos límites -- ocurren en situaciones muy inusuales en las cuales se desarrollan las condiciones más extrañas. Apesar de ser inusuales los casos límites probocan alrededor de 80% de las frustraciones de los usuarios!
Los usuarios típicos de olvidan de las 100 veces que una aplicación funciona correctamente pero recuerdan claramente la vez que no lo hace. Si podes manejar los casos límite -y los casos dificiles-suavemente, entonces vas a tener contenidos a los usuarios que volveran a tu sitio.

Errores
Una vez que hayas tenido cuidado con el código de estado 200 y te hayas dado cuenta de que podes ignorar rotundamente la familia de códigos de estado 300, el otro grupo de códigos que queda para preocuparse es la familia 400, que indica varios tipos de error. Mirar de nuevo el listin 7 y notar que mientras se manejan los errores, solamente se muestra al usuario un mensaje de error genérico. Mientras este es un paso en la direccion corretam, es aun un mensaje bastante inutil a losefectos de decirle al usuario o programador que está trabajando en la aplicación que es lo que realmente esta mál.
Primero, agregar soporte a las paginas perdidas. Esto no pasa mucho en los sistemas de producción, pero no es raro en pruebas para mover un script o que un programador ingrese una URL incorrecta. Si podes reportar los errores 404 con gracia, vas a proveer mucha mas ayuda a los usuarios y programadores confundidos. Por ejemplo, si un script en el servidor fue removido y usas el codigo en el listing 7, verías un error no descriptivo como el que se muestra en la figura 5.

Figura 5. Manejo de error genérico

El usuario no tiene manera de decirte si el problema es de autenticación, o un scrip perdido (que es el caso acá), o un error de usuario, o más si algo en el código causó el problema o no. Un poco de código simple adicional puede hacer este error mucho más especifico. Hechale una ojeda al listing 8 que trata los script perdidos, así como errores de autenticación con un mensaje especifico.

Listing 8. Controlar el código de estado válido

function updatePage(){
if (request.readyState == 4){
if (request.status == 200){
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML = response[1].replace)/\n/g, "<br /&g;");
} else if (request.status == 404){
alert ("No se encontro URL solicitada.");
}else if (request.status == 403){
alert ("Acceso denegado.");
}else
alert ("El estado es " + request.status);
}
}

Esto es todavía bastante simple, pero provee algo de información adicional. La figura 6 muestra el mismo error que en la figura 5, pero esta vez el código tratador de error da una mucho mejor imagen de que esta pasando al usuario o programador.

Figura 6. Gestión de error especifica.

En tus propias aplicaciones, podrias considerar despejar el nombre de usuario y la contraseña cuando ocurre una falla de autenticación y agregar un mensaje de error a la pantalla. Pueden ser aplicadas mejoras similares para una gestion mas amigable de los script perdidos u otros errores tipo 400 (tal como el 405 para un método de petición inaceptable como enviar una petición HEAD que no está permitida o 407 en la que se requiere autenticacion de proxy). Cuaquier elección que hagas, empieza con la gestión del código de estado devuelto por el servidor.