Esta questão trata da alteração do URL no navegador sem realmente navegar para esse URL. Também encontrei vários sites onde isso é usado e acho confuso / enganoso para o usuário e estou me perguntando por que isso é permitido em primeiro lugar.
Pergunta: Por que os agentes/navegadores têm permissão para alterar a URL sem realmente navegar para esse caminho? Qual é o ganho em permitir isso enquanto a desvantagem é confundir o usuário.
Há muito tempo, os Webapps são capazes de alterar totalmente o conteúdo da página usando apenas JavaScript. Por exemplo, no Twitter, você pode navegar da linha do tempo principal para um perfil para um tweet específico inteiramente do lado do cliente, sem qualquer recarga de página – apenas atualizações baseadas em JavaScript.
O problema com isso é que se torna impossível copiar, marcar ou compartilhar o URL em que você aparentemente está. Se você começar em
https://twitter.come abrir, por exemplo, um tweet ou uma página de perfil, sua barra de endereços ainda pensará que você está emhttps://twitter.com. Você também não pode clicar no botão "Voltar" - você sairia de todo o aplicativo.Muitos sites tentaram contornar isso alterando apenas a
#hashparte da URL (que é usada para links de páginas internas), geralmente de uma forma que a torna semelhante a um caminho real – por exemplo, clicar em @stackoverflow altera parahttps://twitter.com/#!/stackoverflow.Agora a URL pode ser copiada e marcada como favorita, mas ainda tem problemas – ela só é compreendida pelo JS do lado do cliente, e não por mecanismos de busca ou navegadores com JS desabilitado/bloqueado ou mesmo ferramentas HTTP como wget/curl. Para todas essas ferramentas e programas, a parte após # não tem sentido (já que aponta para dados gerados dinamicamente por JS e não para um nome real= ou id=).
É por isso que a API foi adicionada para gerar eventos de histórico "reais" por meio de JS - ela permite que cada página baseada em JS tenha uma URL que corresponda exatamente a uma página baseada em servidor real. Quando você clica em um link de perfil, o JS gera a mesma página que você teria sem o JS (só que mais rápido) e, portanto, também tem a mesma URL.
Se você usar esta API, é claro que você deve gerar apenas caminhos que realmente existem no servidor e correspondem a URLs reais - como no exemplo acima, quando o JavaScript altera o URL para
https://twitter.com/stackoverflow, tudo bem porque esta é uma página real que pode ser visitado posteriormente, com o mesmo conteúdo e tudo. Acontece que a página foi carregada via JS e não via navegação, mas essa diferença deveria ser praticamente invisível.Portanto, "a desvantagem é confundir o usuário" só é verdade quando a API é mal utilizada , por exemplo, gerando URLs que o servidor não reconhece posteriormente.