Em 2005, Jesse James Garrett escreveu um artigo "Ajax - Uma Nova Abordagem para Aplicações Web", que descrevia uma aplicação chamada Ajax (tecnologia Asynchronous JavaScript+XML). Essa técnica envolve enviar ao servidor uma solicitação de dados adicionais sem atualizar a página, resultando em uma melhor experiência do usuário. Garrett explica como esta tecnologia muda o modelo tradicional de clicar e esperar que persiste desde o nascimento da Web.
A principal tecnologia que levou o Ajax ao palco histórico é o objeto XMLHttpRequest (XHR). Antes do advento do XHR, a comunicação no estilo Ajax tinha que ser alcançada por meio de alguma tecnologia preta, principalmente usando painéis ocultos ou painéis embutidos. XHR fornece uma interface razoável para enviar solicitações de servidor e obter respostas. Essa interface pode obter dados adicionais do servidor de forma assíncrona, o que significa que os usuários podem obter dados sem atualizar a página. Após obter os dados por meio do objeto XHR, você pode usar métodos DOM para inserir os dados na página web.
A API de objeto XHR é geralmente considerada difícil de usar, e a API Fetch rapidamente se tornou um padrão alternativo mais moderno para XHR após seu nascimento automático. A API Fetch oferece suporte a promessas agendadas e threads de serviço (service workers) e se tornou uma web extremamente poderosa. ferramenta de desenvolvimento.
Uma limitação importante da comunicação Ajax através do XHR é a política de segurança entre origens. Por padrão, o XHR só pode acessar recursos no mesmo domínio da página que iniciou a solicitação. Esta restrição de segurança evita determinados comportamentos maliciosos. No entanto, os navegadores também precisam oferecer suporte ao acesso legal entre origens.
O Cross-Origin Resource Sharing (CORS) define como navegadores e servidores implementam a comunicação entre origens. A ideia básica por trás do CORS é usar cabeçalhos HTTP personalizados para permitir que o navegador e o servidor se entendam para determinar se uma solicitação ou resposta deve ser bem-sucedida ou falhar.
Para solicitações simples, como solicitações GET ou POST, não há cabeçalhos personalizados e o corpo da solicitação é do tipo texto/sem formatação. Essas solicitações terão um cabeçalho adicional chamado Origin quando enviadas. O cabeçalho Origin contém a origem (protocolo, nome de domínio, porta) da página que envia a solicitação para que o servidor possa determinar se deve fornecer uma resposta para ela.
Os navegadores modernos oferecem suporte nativo ao CORS por meio do objeto XMLHttpRequst, que é acionado automaticamente ao tentar acessar recursos de diferentes origens. Para enviar uma solicitação para uma origem em um domínio diferente, você pode usar um objeto XHR padrão e passar uma URL absoluta para o método open(), por exemplo:
let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
if(xhr.readyState == 4){
if((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304){
alerta(xhr.reaponseText);
}outro{
alert("A solicitação não foi bem sucedida:"+xhr.status);
}
}};xhr.open("get","http://www.nezha.con/page/",true);xhr.send(null); Objetos XHR entre domínios permitem acesso às propriedades status e statusText, e também permitem solicitações de sincronização de objetos XHR entre domínios que também impõem algumas restrições adicionais por motivos de segurança.
Você não pode usar setRequestHeader() para definir cabeçalhos personalizados;
você não pode enviar e receber cookies;
o método getAllResponseHeaders() sempre retorna uma string vazia
porque a mesma interface é usada para solicitações de mesmo domínio e de domínio cruzado
;acessando recursos locais Use URLs relativos e URLs absolutos ao acessar recursos remotos. Isso pode distinguir mais claramente os cenários de uso e evitar o problema de acesso restrito a informações de cabeçalho ou cookie ao acessar recursos locais.
O CORS usa um mecanismo de verificação de servidor chamado solicitação de comprovação, permitindo o uso de cabeçalhos personalizados, métodos diferentes de GET e POST e diferentes tipos de conteúdo do corpo da solicitação. Ao enviar uma solicitação envolvendo uma das opções avançadas acima, uma solicitação de comprovação é enviada primeiro ao servidor. Esta solicitação é enviada através do método OPTIONS e contém os seguintes cabeçalhos:
Origin: o mesmo que uma solicitação simples
-
Control-Request-Method: o método que você deseja usar;
-valores separados para usar Lista de cabeçalhos personalizados
A API Fetch pode realizar todas as tarefas do objeto XMLHttpRequest, mas é mais fácil de usar, a interface é mais moderna e pode ser usada em ferramentas Web como como Threads de trabalho da Web. XMLHttpRequest pode optar por ser assíncrono, enquanto a API Fetch deve ser assíncrona.
O método fetch() é exposto no escopo global, incluindo o thread de execução da página principal, módulos e threads de trabalho. Chamar esse método faz com que o navegador envie uma solicitação para o URL fornecido.
1. Solicitação de envio
fetch() possui apenas uma entrada de parâmetro obrigatória. Na maioria dos casos, este parâmetro é a URL para obter o recurso, e este método retorna uma promessa:
let r = fetch('/bar');console.log(r);//Promise<pending> Formato da URL (caminho relativo , caminhos absolutos, etc.) são interpretados da mesma forma que objetos XHR.
Quando a solicitação for concluída e os recursos estiverem disponíveis, um objeto Response será processado. Este objeto é um encapsulamento da API através do qual os recursos correspondentes podem ser obtidos. Use as propriedades e métodos deste objeto para obter recursos, compreender a resposta e converter o balanceamento de carga em um formato útil.
2. Leia a resposta A maneira mais simples de ler o conteúdo da resposta é obter o conteúdo em formato de texto simples, basta usar o método text(). Este método retorna uma promessa, que resolve a recuperação do conteúdo completo do recurso.
3. Tratamento de códigos de status e falhas de solicitação
A API Fetch oferece suporte à verificação do status da resposta por meio das propriedades status e statusText de Response. As solicitações que obtêm uma resposta com êxito geralmente produzem um código de status com valor 200.
4. Modos comuns de solicitação de busca:
enviar dados JSON,
enviar parâmetros no corpo da solicitação,
enviar arquivos
, carregar arquivos Blob
, enviar solicitações entre domínios,
interromper solicitações
Soquete Websocket O objetivo do websocket é atingir full-duplex e dois- forma de comunicação com o servidor através de uma conexão de longo prazo. Ao criar um websocket em JavaScript, uma solicitação HTTP é enviada ao servidor para inicializar a conexão. Depois que o servidor responde, a conexão muda do protocolo HTTP para o protocolo websocket usando o cabeçalho Upgrade em HTTP, o que significa que o websocket não pode ser implementado por meio de um servidor HTTP padrão, mas deve usar um servidor proprietário que suporte este protocolo.
Como o websocket usa um protocolo personalizado, o esquema de URL mudou ligeiramente. http:// ou https:// não pode mais ser usado, mas ws:// e wss:// devem ser usados. A primeira é uma conexão insegura e a segunda é uma conexão segura. Ao executar URLs de websocket, o esquema de URL deve ser incluído, pois é possível que esquemas adicionais sejam suportados no futuro.
A vantagem de usar um protocolo personalizado em vez do protocolo HTTP é que o cliente e o servidor podem enviar muito poucos dados sem sobrecarregar o HTTP. O uso de pacotes de dados menores torna os websockets ideais para aplicações móveis onde os problemas de largura de banda e latência são significativos. A desvantagem de usar um protocolo personalizado é que a definição do protocolo leva mais tempo do que a definição da API JavaScript que é suportada por todos os principais navegadores.
