柠檬铺

在 Web 浏览器环境中，History 通常意味着后退按钮，并且管理起来一直很难。随着 AJAX 在 Web 应用程序中变得愈发重要并且典型的网站开始发展成更丰富的 Web 应用程序后，History 甚至变得更具挑战性。而随着 JavaScript 变成默认情况下启用（而不是禁用），频繁使用客户端 JavaScript 的单页 Web 应用程序出现了。但是，过去没有很好的方法可用来处理客户端存储、数据库、甚至页之间的一般状态。
然而现在，HTML5 采用了客户端状态管理，并且引入了一套全新的 API，包括 IndexedDB、本地存储以及 History API 之类的规范，在本文中我们将着重介绍 History API。
简言之，History API 的目标是为丰富 JavaScript 应用程序提供一个方法，以便不仅可以更好地导航会话历史记录，还可以管理其状态并且为 URL 提供一流的支持。这意味着，使用几个简单的 API 调用和事件，您就可以在保持很好的 URL 结构的同时进行浏览，并且将状态数据推送和弹出到会话堆栈，以便影响后退按钮的操作方式等。

问题

在您使用任何解决方案时，理解问题十分重要。History API 并不仅仅是在最终用户单击后退和前进按钮时可以神奇地保持页面状态。尽管确实是这样，但真相往往隐蔽得更深。从用户的角度来说，任何浏览器都有两个主要的功能： URL 和导航按钮（前进和后退）。它们一起允许用户跨 Internet 请求或浏览一系列文档。
尽管这些功能多年以来一直在本质上保持没有变化，但随着 AJAX 流行开来，其背后的事情也随之发生了改变。在一系列文档成为只是具有 AJAX 调用的单个文件的背后蕴含的是什么呢？这很棒了；我们只需使用少量的异步就可以提供更丰富的体验，更别提性能和用户体验上的改进了。但是，它也带来了一些问题；跟踪 URL 的挑战会更加艰巨得多，例如，跟踪 URL 以便在用户单击后退或刷新时知道浏览器应转到何处。
我认为不能忽略 URL 的重要性。URL 是永久的： 用户喜欢它们，搜索引擎对它们建立索引，而公司靠它们开拓市场。如何在日新月异的 Web 世界管理 URL 呢？
输入哈希符号 (#) 和 hashbang (#!)。浏览器会将 # 后的任何内容视作 URL 片段标识符，并且永远不会将其发送到服务器。该哈希符号最初表示在页内链接的定位标记，但它逐渐用于 AJAX 相关的活动。但在 AJAX 的早期，仅具有哈希符号的 URL 将不会由搜索引擎建立索引。对此的解决方法就是 hashbang，它使 Web 应用程序能够使用和修改 URL 并让搜索引擎对其建立索引，而不会使页请求返回到服务器。包含 hashbang 的 URL（例如 twitter.com/#!replies）随着 Web 应用程序的出现而变得重要起来。

新的 History API

尽管这已是一个很大的进步，但还没有来自浏览器的任何真正意义上的正式支持。Web 应用程序只是为了推动其发展而玩了一把脚本撰写游戏。新的 History API 着重于使 Web 应用程序能够“管理状态”，这意味着跟踪构成一个会话的历史记录的文档序列。这使您可以导航会话历史记录并且永久保存状态数据 — 以及正确处理 URL。在开始介绍这个 API 之前，应该看一下万维网联盟或 W3C (bit.ly/MU89iZ) 规定的实际接口定义：

绝对称不上复杂的 API。