Para muitos desenvolvedores Web, gerar solicitações simples e receber respostas simples é suficiente, mas para desenvolvedores que desejam dominar o Ajax, é necessário um entendimento completo dos códigos de status HTTP, dos estados prontos e do objeto XMLHttpRequest. Neste artigo, Brett McLaughlin apresenta os vários códigos de status e mostra como os navegadores os tratam. Ele também analisa algumas das solicitações HTTP menos comuns usadas no Ajax.
No artigo anterior desta série, examinamos mais de perto o objeto XMLHttpRequest, que é a peça central de um aplicativo Ajax e é responsável por lidar com solicitações de aplicativos e scripts do lado do servidor e processar dados retornados de componentes do lado do servidor. Como todos os aplicativos Ajax usam o objeto XMLHttpRequest, você pode querer se familiarizar com esse objeto para que o Ajax possa ter um melhor desempenho.
Neste artigo, focarei nas três partes principais deste objeto de solicitação com base no artigo anterior:
· Status pronto para HTTP · Código de status HTTP · Os tipos de solicitação que podem ser gerados
Essas três partes são fatores a serem considerados na construção de um
.quando solicitado; no entanto, muito pouco foi escrito sobre estes temas. No entanto, se quiser aprender mais do que apenas o básico da programação Ajax, você precisará se familiarizar com o conteúdo dos estados prontos, dos códigos de status e das próprias solicitações. Quando algo dá errado com seu aplicativo - e sempre acontece - se você entender corretamente o estado de prontidão, como gerar uma solicitação HEAD ou o que exatamente significa um código de status 400, você poderá depurar o problema em 5 minutos em vez de 5 horas gastas em diversas frustrações e confusões.
Vejamos primeiro o estado pronto para HTTP.
Uma análise mais detalhada do estado pronto para HTTP
Você se lembrará do artigo anterior que o objeto XMLHttpRequest possui uma propriedade chamada readyState. Este atributo garante que o servidor concluiu uma solicitação, normalmente usando uma função de retorno de chamada para ler dados do servidor para atualizar o conteúdo do formulário ou página da Web. A Listagem 1 mostra um exemplo simples (também é um exemplo do artigo anterior desta série – consulte Recursos).
XMLHttpRequest ou XMLHttp: uma mudança de nome
A Microsoft™ e o Internet Explorer usam um objeto chamado XMLHttp em vez do objeto XMLHttpRequest, que é usado pelo Mozilla, Opera, Safari e pela maioria dos navegadores que não são da Microsoft. Para simplificar, chamarei ambos os objetos simplesmente de XMLHttpRequest. Isso é consistente com o que vemos na Web e com a intenção da Microsoft de usar XMLHttpRequest como objeto de solicitação no Internet Explorer 7.0. (Consulte a Parte 2 para obter mais informações sobre esse problema.)
Listagem 1. Manipulando a resposta do servidor em um retorno de chamada
function updatePage() {
if (request.readyState == 4) {
if (solicitação.status == 200) {
var resposta = request.responseText.split("|");
document.getElementById("pedido").valor = resposta[0];
document.getElementById("endereço").innerHTML =
resposta[1].replace(/n/g, "<br />");
} outro
alert("o status é " + request.status);
}
}
Este é obviamente o uso mais comum (e mais simples) do estado pronto. Como você pode perceber pelo número "4", existem vários outros estados prontos (você também viu esta lista no artigo anterior - consulte Recursos):
· 0: A solicitação não foi inicializada ( open() ainda não foi chamado) .
·1: A solicitação foi estabelecida, mas não foi enviada (send() ainda não foi chamado).
·2: A solicitação foi enviada e está sendo processada (normalmente os cabeçalhos do conteúdo agora podem ser obtidos a partir da resposta).
·3: A solicitação está sendo processada; normalmente alguns dados estão disponíveis na resposta, mas o servidor ainda não concluiu a geração da resposta.
·4: A resposta está completa; você pode obter e usar a resposta do servidor.
Se você quiser entender mais do que o básico da programação Ajax, precisará conhecer não apenas esses estados, mas também quando eles ocorrem e como usá-los. Primeiro, você precisa saber quais estados de solicitação você pode encontrar em cada estado de prontidão. Infelizmente, isto não é intuitivo e envolve vários casos especiais.
Estado pronto oculto
O primeiro estado pronto é caracterizado pelo atributo readyState ser 0 (readyState == 0), indicando um estado não inicializado. Esta propriedade é definida como 1 quando open() é chamado no objeto de solicitação. Como você normalmente chama open() imediatamente após inicializar um par de solicitações, raramente verá um estado readyState == 0. Além disso, o estado pronto não inicializado não tem uso real em aplicações reais.
Mas, para nosso interesse, consulte a Listagem 2, que mostra como obter esse estado pronto quando readyState está definido como 0.
Listagem 2. Obtendo status 0 pronto
function getSalesData() {
//Cria um objeto de solicitação
criarRequest();
alert("O estado pronto é: " + request.readyState);
// Configurar (inicializar) a solicitação
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, verdadeiro);
request.onreadystatechange = updatePage;
solicitação.enviar(nulo);
}
Neste exemplo simples, getSalesData() é a função que a página da Web chama para iniciar uma solicitação (como quando um botão é clicado). Observe que você deve verificar o status de pronto antes de chamar open(). A Figura 1 mostra os resultados da execução deste aplicativo.
Figura 1. Estado Pronto 0
Obviamente, isso não significa muito para você; existem poucas situações em que você precisa ter certeza de que a função open() ainda não foi chamada. No mundo real da maior parte da programação Ajax, o único uso desse estado pronto é usar o mesmo objeto XMLHttpRequest para gerar diversas solicitações em diversas funções. Neste caso (incomum), você pode querer garantir que o objeto de solicitação esteja em um estado não inicializado (readyState == 0) antes de gerar uma nova solicitação. Basicamente, isso garante que outra função não esteja usando o objeto ao mesmo tempo.
Visualize o estado de prontidão da solicitação que está sendo processada
. Além do estado pronto 0, o objeto de solicitação também precisa passar por vários outros estados prontos de solicitações e respostas típicas e, finalmente, termina na forma do estado pronto 4. É por isso que você vê a linha if (request.readyState == 4) na maioria das funções de retorno de chamada, ela garante que o servidor concluiu o processamento da solicitação e agora é seguro atualizar a página da web ou atualizar a página com base na solicitação retornada; dos dados do servidor para executar operações.
É muito simples ver como esse estado ocorre. Se o status de pronto for 4, não apenas teremos que executar o código na função de retorno de chamada, mas também imprimiremos o status de pronto cada vez que a função de retorno de chamada for chamada. A Listagem 3 dá um exemplo de implementação dessa funcionalidade.
Quando 0 é igual a 4
, você precisa verificar o status de pronto 0 para garantir que o objeto de solicitação não esteja em uso quando várias funções JavaScript usam o mesmo objeto de solicitação. Esse mecanismo pode causar problemas. Como readyState == 4 representa uma solicitação concluída, muitas vezes você descobrirá que os objetos de solicitação no estado pronto que não estão sendo usados no momento ainda estão definidos como 4 - isso ocorre porque os dados retornados do servidor já foram usados, mas não. alterações foram feitas desde que foram definidas para o estado pronto. Existe uma função abort() que redefine o objeto de solicitação, mas esta função não é realmente usada para esse propósito. Se você precisar usar diversas funções, é melhor criar e usar uma função para cada função, em vez de compartilhar o mesmo objeto entre diversas funções.
Listagem 3. Visualizar
função de prontidão updatePage() {
// Mostra o estado pronto atual
alert("updatePage() chamado com estado pronto de " + request.readyState);
}
Se você não tiver certeza de como executar esta função, será necessário criar uma função, chamar essa função na página da Web e fazer com que ela envie uma solicitação ao componente do lado do servidor (como a função mostrada na Listagem 2, ou a função nesta série de artigos) Exemplos dados na Parte 1 e Parte 2). Certifique-se de definir a função de retorno de chamada como updatePage() ao fazer a solicitação; para fazer isso, defina a propriedade onreadystatechange do objeto de solicitação como updatePage().
Este código é uma demonstração exata do significado de onreadystatechange - toda vez que o estado pronto da solicitação muda, updatePage() é chamado e então podemos ver um aviso. A Figura 2 mostra um exemplo de chamada desta função, onde o status pronto é 1.
Figura 2. Estado Pronto 1
Você pode tentar executar este código sozinho. Coloque-o em uma página da Web e ative o manipulador de eventos (clique em um botão, tabule entre os campos ou use qualquer método definido para acionar a solicitação). Esta função de retorno de chamada será executada várias vezes - cada vez que o estado de prontidão for alterado - e você poderá ver o aviso para cada estado de prontidão. Esta é a melhor maneira de acompanhar os vários estágios pelos quais uma solicitação passa.
Inconsistências do navegador
Depois de ter uma compreensão básica do processo, tente acessar sua página em alguns navegadores diferentes. Você deve notar que os navegadores são inconsistentes na forma como lidam com esses estados prontos. Por exemplo, no Firefox 1.5, você veria os seguintes estados prontos:
·1
·2
·3
·4
Isto não é surpreendente, uma vez que o status de cada solicitação é representado aqui. No entanto, se você usar o Safari para acessar o mesmo aplicativo, deverá ver – ou não – algo interessante. Esta é a aparência no Safari 2.0.1:
·2
·3
·4
O Safari realmente descarta o primeiro estado pronto, e não há nenhuma razão óbvia para isso, mas é assim que o Safari funciona. Isso também ilustra um ponto importante: embora seja uma boa ideia garantir que o status da solicitação seja 4 antes de usar os dados no servidor, o código escrito para depender de cada estado de transição pronto terá resultados diferentes em navegadores diferentes.
Por exemplo, ao usar o Opera 8.5, o status de prontidão exibido é ainda pior:
·3
·
4Finalmente, o Internet Explorer exibirá o seguinte status:
·1
·2
·3
·4Se
você tiver problemas com suas solicitações, este é o primeiro lugar para identificar o problema. A melhor maneira é testar isso no Internet Explorer e no Firefox - você verá todos os 4 estados e poderá verificar em que estado está cada solicitação.
A seguir, vamos dar uma olhada na situação do lado da resposta.
Dados de resposta sob o microscópio
Depois de entendermos os vários estados de prontidão que ocorrem durante o processo de solicitação, é hora de examinar outro aspecto do objeto XMLHttpRequest – o atributo responseText. Lembrando o que apresentamos no artigo anterior, você pode saber que este atributo é usado para obter dados do servidor. Depois que o servidor terminar de processar a solicitação, ele poderá colocar quaisquer dados necessários para responder aos dados da solicitação no responseText da solicitação. A função de retorno de chamada pode então usar esses dados, conforme mostrado na Listagem 1 e na Listagem 4.
Listagem 4. Utilizando a resposta retornada no servidor
function updatePage() {
if (request.readyState == 4) {
var novoTotal = request.responseText;
var totalSoldEl = document.getElementById("total vendido");
var netProfitEl = document.getElementById("lucro líquido");
replaceText(totalSoldEl, newTotal);
/* Imagine o novo lucro líquido */
var boardCostEl = document.getElementById("custo da placa");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("custo-homem");
var manCost = getText(manCostEl);
varprofitPerBoard = boardCost - manCost;
var netProfit =profitPerBoard * newTotal
/* Atualiza o lucro líquido no formulário de vendas */
netProfit = Math.round(netProfit * 100) / 100;
substituaText(netProfitEl, netProfit);
A Listagem
1 é bastante simples; a Listagem 4 é um pouco mais complicada, mas ambas verificam o estado pronto no início e obtêm o valor da propriedade responseText.
Visualizando o texto de resposta de uma solicitação
Semelhante ao estado pronto, o valor da propriedade responseText também muda ao longo da vida da solicitação. Para ver essa mudança, use o código mostrado na Listagem 5 para testar o texto de resposta da solicitação, bem como seu status de prontidão.
Listagem 5. Testando a propriedade responseText
function updatePage() {
// Mostra o estado pronto atual
alert("updatePage() chamado com estado pronto de " + request.readyState +
" e um texto de resposta de '" + request.responseText + "'");
}
Agora abra a aplicação web em seu navegador e ative sua solicitação. Para ver melhor o efeito deste código, use o Firefox ou o Internet Explorer, pois ambos os navegadores podem reportar todos os possíveis estados de prontidão durante a solicitação. Por exemplo, no estado pronto 2, responseText não está definido (veja a Figura 3); se o console JavaScript também estiver aberto, você verá um erro.
Figura 3. Texto de resposta para status pronto 2
Entretanto, no estado pronto 3, o servidor colocou um valor na propriedade responseText, pelo menos neste exemplo (veja a Figura 4).
Figura 4. Texto de resposta para status pronto 3
Você verá que a resposta com status pronto 3 é diferente em cada script, cada servidor e até mesmo em cada navegador. No entanto, isso ainda é muito útil na depuração de aplicativos.
Obtenção de dados seguros
Todos os documentos e especificações enfatizam que os dados só podem ser utilizados com segurança quando o status de prontidão for 4. Acredite, quando o estado pronto é 3, você raramente encontrará uma situação em que não consiga obter dados da propriedade responseText. No entanto, não é uma boa ideia tornar sua própria lógica em seu aplicativo dependente do estado pronto 3 - depois de escrever um código que depende de dados completos no estado pronto 3, você será quase responsável pelos dados incompletos naquele momento.
Uma abordagem melhor é fornecer algum feedback ao usuário de que, quando estiver no estado pronto 3, a resposta será em breve. Embora usar funções como alert() seja obviamente uma má ideia - usar Ajax e bloquear o usuário com uma caixa de diálogo de alerta é obviamente errado - você pode atualizar campos em um formulário ou página quando o estado pronto mudar. Por exemplo, para o estado pronto 1, defina a largura do indicador de progresso para 25%, para o estado pronto 2, defina a largura do indicador de progresso para 50%, e para o estado pronto 3, defina a largura do indicador de progresso para 25 % A largura é definida como 75% e quando o estado pronto é 4, a largura do indicador de progresso é definida como 100% (concluído).
Claro, como você já viu, esse método é muito inteligente, mas depende do navegador. No Opera você nunca vê os dois primeiros estados prontos e no Safari não há o primeiro (1). Por esse motivo deixei esse código como exercício e não o incluí neste artigo.
Agora é hora de examinar os códigos de status.
Uma análise mais aprofundada dos códigos de status HTTP
Com o estado pronto e a resposta do servidor que você aprendeu em Técnicas de programação Ajax, você pode adicionar outro nível de complexidade aos seus aplicativos Ajax – usando códigos de status HTTP. Não há nada de novo sobre o Ajax neste código. Eles existem desde o surgimento da Web. Você pode ter visto vários códigos de status em navegadores da Web:
· 401: Não autorizado · 403: Proibido · 404: Não encontrado
Você pode encontrar mais códigos de status (consulte Recursos para obter uma lista completa). Para adicionar uma camada adicional de mecanismos de controle e resposta (e tratamento de erros mais robusto) aos seus aplicativos Ajax, você precisa visualizar corretamente os códigos de status em solicitações e respostas.
200: Everything is OK
Em muitas aplicações Ajax, você verá uma função de retorno de chamada que é responsável por verificar o status de prontidão e depois continuar a utilizar os dados retornados da resposta do servidor, conforme mostrado na Listagem 6.
Listagem 6. Função de retorno de chamada que ignora o código de status
function updatePage() {
if (request.readyState == 4) {
var resposta = request.responseText.split("|");
document.getElementById("pedido").valor = resposta[0];
document.getElementById("endereço").innerHTML =
resposta[1].replace(/n/g, "<br />");
}
}
Esta é uma abordagem míope e errada para a programação Ajax. Se o script exigir autenticação e a solicitação não fornecer um certificado válido, o servidor retornará um código de erro como 403 ou 401. Entretanto, como o servidor respondeu à solicitação, o status pronto é definido como 4 (mesmo que a resposta não tenha sido a esperada pela solicitação). Em última análise, o usuário não obtém dados válidos e erros graves podem ocorrer quando o JavaScript tenta usar dados do servidor que não existem.
É necessário um esforço mínimo para garantir que o servidor não apenas conclua uma solicitação, mas também retorne um código de status "tudo bom". Este código é "200", que é reportado através do atributo status do objeto XMLHttpRequest. Para garantir que o servidor não apenas concluiu uma solicitação, mas também relatou um status OK, adicione outra verificação à sua função de retorno de chamada, conforme mostrado na Listagem 7.
Listagem 7. Verificando códigos de status válidos
function updatePage() {
if (request.readyState == 4) {
if (solicitação.status == 200) {
var resposta = request.responseText.split("|");
document.getElementById("pedido").valor = resposta[0];
document.getElementById("endereço").innerHTML =
resposta[1].replace(/n/g, "<br />");
} outro
alert("o status é " + request.status);
}
}
Ao adicionar essas poucas linhas de código, você pode confirmar se há algum problema e o usuário verá uma mensagem de erro útil em vez de apenas ver uma página composta de dados retirados do contexto sem explicação.
Redirecionamentos e redirecionamentos
Antes de entrarmos em detalhes sobre erros, vale a pena discutir um problema com o qual você não precisa se preocupar ao usar Ajax – redirecionamentos. Entre os códigos de status HTTP, esta é a série 300 de códigos de status, incluindo:
301: Movido permanentemente 302: Encontrado (solicitação redirecionada para outro URL/URI)
·305: Usando um proxy (a solicitação deve usar um proxy para acessar o recurso solicitado)
Os programadores Ajax podem não estar muito preocupados com problemas de redirecionamento, por dois motivos:
·Primeiro, os aplicativos Ajax são geralmente projetados para serem escritos para um servidor específico script, servlet ou aplicativo. Os programadores Ajax são menos claros sobre os componentes que desaparecem sem que você os veja. Então, às vezes você sabe que o recurso foi movido (porque você o moveu ou o moveu de alguma forma) e então modifica o URL na solicitação e nunca mais encontra esse resultado.
Um motivo mais importante é que os aplicativos e solicitações Ajax são encapsulados em uma sandbox. Isso significa que o domínio que atende as páginas da Web que geram solicitações Ajax deve ser o domínio que responde a essas solicitações. Portanto, a página da Web fornecida por ebay.com não pode fazer uma solicitação no estilo Ajax para um script em execução em amazon.com; um aplicativo Ajax em ibm.com não pode fazer uma solicitação para servlets em execução em netbeans.org.
·O resultado é que sua solicitação não pode ser redirecionada para outro servidor sem gerar um erro de segurança. Nesses casos, você não receberá nenhum código de status. Normalmente, um erro de JavaScript é gerado no console de depuração. Portanto, depois de pensar bastante nos códigos de status, você pode ignorar completamente o problema dos códigos de redirecionamento.
O resultado é que sua solicitação não pode ser redirecionada para outro servidor sem gerar um erro de segurança. Nesses casos, você não receberá nenhum código de status. Normalmente, um erro de JavaScript é gerado no console de depuração. Portanto, depois de pensar bastante nos códigos de status, você pode ignorar completamente o problema dos códigos de redirecionamento.
Erros
Depois de receber o código de status 200 e perceber que você pode ignorar amplamente os códigos de status da série 300, o único conjunto de códigos com o qual você precisa se preocupar são os códigos da série 400, que ilustram os diferentes tipos de erros. Reveja a Listagem 7 e observe que, ao tratar erros, apenas algumas mensagens de erro comuns são enviadas ao usuário. Embora este seja um passo na direção certa, essas mensagens ainda não são muito úteis para informar aos usuários e programadores que trabalham no aplicativo o que exatamente está errado.
Primeiro, adicionaremos suporte para páginas não encontradas. Na verdade, isso não deveria acontecer na maioria dos sistemas de produção, mas não é incomum quando a localização do script de teste muda ou o programador insere a URL errada. Se você puder relatar erros 404 naturalmente, poderá fornecer mais ajuda a usuários e programadores frustrados. Por exemplo, se um script no servidor for excluído, podemos usar o código da Listagem 7 para que o usuário veja um erro não descritivo como o mostrado na Figura 5.
Casos extremos e situações difíceis
Neste ponto, alguns programadores novatos podem se perguntar do que se trata. Aqui está um fato que você precisa saber: menos de 5% das solicitações Ajax usam estados prontos como 2 e 3 e códigos de status como 403 (na verdade, essa taxa provavelmente está mais próxima de 1% ou até menos). Essas situações são muito importantes e são chamadas de casos extremos – elas ocorrem apenas em situações muito específicas onde os problemas mais exóticos são encontrados. Embora essas situações não sejam comuns, esses casos extremos são responsáveis por 80% dos problemas que a maioria dos usuários encontra.
Para o usuário típico, o fato de o aplicativo funcionar corretamente 100 vezes é geralmente esquecido, no entanto, um erro no aplicativo será claramente lembrado por! eles. Se você conseguir lidar bem com casos extremos (ou situações difíceis), poderá oferecer recompensas satisfatórias aos usuários que retornarem ao seu site.
Figura 5. Tratamento de erros comuns
O usuário não tem como saber se o problema é uma questão de autenticação, um script não encontrado (como é o caso aqui), erro do usuário ou qualquer outra coisa no código. Adicionar algum código simples pode tornar esse erro mais específico. Consulte a Listagem 8, que é responsável por tratar a situação em que o script não é encontrado ou ocorre um erro de autenticação, e mensagens específicas serão fornecidas quando esses erros ocorrerem.
Listagem 8. Verificando códigos de status válidos
function updatePage() {
if (request.readyState == 4) {
if (solicitação.status == 200) {
var resposta = request.responseText.split("|");
document.getElementById("pedido").valor = resposta[0];
document.getElementById("endereço").innerHTML =
resposta[1].replace(/n/g, "<br />");
} senão if (request.status == 404) {
alerta ("URL solicitada não encontrada.");
} senão if (request.status == 403) {
alerta("Acesso negado.");
} outro
alert("o status é " + request.status);
}
}
Embora isso ainda seja bastante simples, ele fornece algumas informações mais úteis. A Figura 6 mostra o mesmo erro da Figura 5, mas desta vez o código de tratamento de erros explica melhor ao usuário ou programador o que exatamente aconteceu.
Figura 6. Tratamento especial de erros
Em nosso próprio aplicativo, podemos considerar limpar o nome de usuário e a senha e adicionar uma mensagem de erro à tela no caso de falha na autenticação. Podemos usar uma abordagem semelhante para lidar melhor com scripts não encontrados ou outros erros do tipo 400 (por exemplo, 405 significa que um método de solicitação inaceitável, como o envio de uma solicitação HEAD, não é permitido e 407 significa que a autenticação de proxy é necessária). No entanto, independentemente da opção escolhida, você precisa começar a processar o código de status retornado do servidor.
Outros tipos de solicitação
Se você realmente deseja ter controle sobre o objeto XMLHttpRequest, considere implementar esta funcionalidade final adicionando a solicitação HEAD à diretiva. Nos dois artigos anteriores, apresentamos como gerar solicitações GET; em um próximo artigo, você aprenderá como usar solicitações POST para enviar dados ao servidor. No entanto, no espírito do tratamento aprimorado de erros e da coleta de informações, você deve aprender como gerar solicitações HEAD.
Fazendo a solicitação
Fazer a solicitação HEAD é realmente muito simples; você chama o método open() com "HEAD" (em vez de "GET" ou "POST") como o primeiro parâmetro, conforme mostrado na Listagem 9.
Listagem 9. Usando Ajax para gerar uma solicitação HEAD
function getSalesData() {
criarRequest();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, verdadeiro);
request.onreadystatechange = updatePage;
solicitação.enviar(nulo);
}
Quando você gera uma solicitação HEAD como essa, o servidor não retorna uma resposta real como faria para uma solicitação GET ou POST. Em vez disso, o servidor retorna apenas o cabeçalho do recurso, que inclui quando o conteúdo da resposta foi modificado pela última vez, se o recurso solicitado existe e muitas outras informações úteis. Você pode usar essas informações para saber mais sobre o recurso antes que ele seja processado e retornado pelo servidor.
A coisa mais simples que você pode fazer para esse tipo de solicitação é simplesmente gerar o conteúdo de todos os cabeçalhos de resposta. Isso lhe dá uma ideia do que está disponível por meio da solicitação HEAD. A Listagem 10 fornece uma função de retorno de chamada simples que imprime o conteúdo do cabeçalho de resposta obtido da solicitação HEAD.
Listagem 10. Produza o conteúdo do cabeçalho de resposta obtido da
função de solicitação HEAD updatePage() {
if (request.readyState == 4) {
alerta(request.getAllResponseHeaders());
}
}
Veja a Figura 7, que mostra os cabeçalhos de resposta retornados de um aplicativo Ajax simples que faz uma solicitação HEAD ao servidor.
Você pode usar esses cabeçalhos individualmente (do tipo de servidor para o tipo de conteúdo) para fornecer informações ou funcionalidades adicionais em seu aplicativo Ajax.
Verificando a URL
Você viu como verificar erros 404 quando a URL não existe. Se isso for um problema comum - talvez um script ou servlet específico esteja faltando - então você pode verificar a URL antes de fazer uma solicitação GET ou POST completa. Para implementar essa funcionalidade, gere uma solicitação HEAD e verifique se há erros 404 na função de retorno de chamada. A Listagem 11 mostra uma função de retorno de chamada simples.
Listagem 11. Verificando se uma URL existe
function updatePage() {
if (request.readyState == 4) {
if (solicitação.status == 200) {
alerta("URL existe");
} senão if (request.status == 404) {
alerta("URL não existe.");
} outro {
alert("O status é: " + request.status);
}
}
}
Honestamente, o valor deste código não é tão grande. O servidor deve responder à solicitação e construir uma resposta para preencher o cabeçalho de resposta Content-Length, de modo que nenhum tempo de processamento seja economizado. Além disso, isso leva tanto tempo quanto gerar a solicitação e usar uma solicitação HEAD para verificar se a URL existe, já que a solicitação é gerada usando GET ou POST, em vez de apenas manipular o código de erro, conforme mostrado na Listagem 7. No entanto, às vezes é útil saber exatamente o que está disponível no momento; você nunca sabe quando sua criatividade entrará em ação ou quando precisará de uma solicitação HEAD!
Solicitações HEAD úteis
Uma área onde você pode achar a solicitação HEAD muito útil é ver a extensão ou o tipo de conteúdo. Isso pode determinar se uma grande quantidade de dados precisa ser enviada de volta para lidar com a solicitação e se o servidor está tentando retornar dados binários em vez de HTML, texto ou XML (todos os três tipos de dados são mais fáceis de processar em JavaScript do que dados binários).
Nesses casos, basta usar o nome de cabeçalho apropriado e passá-lo para o método getResponseHeader() do objeto XMLHttpRequest. Portanto, para obter o comprimento da resposta, basta chamar request.getResponseHeader("Content-Length");. Para obter o tipo de conteúdo, use request.getResponseHeader("Content-Type");.
Em muitas aplicações, gerar uma solicitação HEAD não adiciona nenhuma funcionalidade e pode até fazer com que a solicitação seja mais lenta (forçando uma solicitação HEAD a obter dados sobre a resposta e, em seguida, usando uma solicitação GET ou POST para realmente obter a resposta). No entanto, em situações em que você não tem certeza sobre um script ou componente do lado do servidor, usar uma solicitação HEAD pode obter alguns dados básicos sem realmente processar os dados de resposta ou exigir muita largura de banda para enviar a resposta.
Conclusão
Para muitos programadores Ajax e Web, o material apresentado neste artigo pode parecer muito avançado. Qual é o valor de gerar uma solicitação HEAD? Quando você precisa lidar explicitamente com códigos de status de redirecionamento em JavaScript? Estas são boas perguntas para aplicações simples, a resposta é que o valor destas técnicas avançadas não é muito grande.
No entanto, a web não é mais um lugar onde você só precisa implementar aplicativos simples; os usuários se tornaram mais avançados, os clientes esperam melhor estabilidade, relatórios de erros mais avançados e, se um aplicativo ficar inativo 1% do tempo, o gerente poderá. ser demitido por isso.
Portanto, seu trabalho não pode se limitar a aplicações simples, mas requer um conhecimento mais profundo de XMLHttpRequest.
·Se você puder pensar em vários estados de prontidão — e entender como esses estados de prontidão diferem entre os navegadores — você poderá depurar rapidamente seu aplicativo. Você pode até desenvolver algumas funcionalidades criativas com base no estado de prontidão e relatar o status solicitado aos usuários e clientes.
·Se quiser controlar códigos de status, você pode configurar seu aplicativo para lidar com erros de script, respostas inesperadas e casos extremos. O resultado é um aplicativo que funciona corretamente o tempo todo, e não apenas quando está tudo bem.
·Adicionar a capacidade de gerar solicitações HEAD, verificar se existe um URL e confirmar se um arquivo foi modificado, de modo a garantir que os usuários possam obter páginas válidas e que as informações que os usuários veem sejam as mais recentes (o mais importante) os surpreendam. quão robusto e versátil este aplicativo é.
O objetivo deste artigo não é fazer com que seu aplicativo pareça sofisticado, mas ajudá-lo a remover o holofote amarelo e destacar a beleza do texto ou parecer mais um desktop. Embora todas essas sejam características do Ajax (que serão abordadas nos próximos artigos), elas são como uma camada de creme no bolo. Se você puder usar o Ajax para construir uma base sólida para que seu aplicativo possa lidar bem com erros e problemas, os usuários retornarão ao seu site e aplicativo. No próximo artigo adicionaremos esta técnica intuitiva que fará seus clientes tremerem de entusiasmo. (Sério, você não vai querer perder o próximo artigo!)