History API 标签中有 3 篇文章
既上一篇文章记录了组内单页引擎升级路由为 History API 方式，考虑到不支持该方式的浏览器/WebView，需要多页降级。如果不对 Nginx 进行配置，就会出现404，因为多数通过pushState得到的 URL 并没有真实对应的资源。
采用 History API 方案的 URL 格式如下：
http[s]://hostname/resource/project/page[/view]?arg1=value1
其中 resource 为资源目录，该目录下放置各个不同的项目文件夹，每个项目对应一个 project 目录。一个 project 中可能会有多个单页应用，每个单页应用对应 URL 中的一个 page。一个单页应用下的不同视图分别对应一个 view。因为采用的单页引擎支持默认路由，所以 view 并非必需。
比如 A 项目下有一个 refund 的单页应用，对应的 HTML 资源为 refund.html，为了 URL 的美观，在 URL 中去掉 html 后缀名。refund 管理两个视图 detail 和
之前使用 History API 作为路由方案升级了组内单页视图引擎。完整的实现还需要 Nginx 的辅助配置，因为当页面刷新时，通过pushState到达的路由很可能并不存在对应的资源，所以要使同一个项目下的所有路由匹配到项目对应的单页资源。
其实主要的工作是对3种资源的 uri 配置 rewrite：
对应的配置如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# match img resource location ~ /resource/wa/([\w|-]+)/(img|page)/(.*) { rewrite ^/resource/wa/([\w|-]+)/(img|page)/(.*)$ /resource/$1/$2/$3 last; } location ~ /resource/wa/([\w|-]+)/([\w|-]+)/(img|page)/(.*) { rewrite ^/resource/wa/([\w|-]+)/([\w|-]+)/(img|page)/(.*)$ /resource/$1/$3/$4 last; } # match HTML resource location ~ /resource/wa/([\w|-]+)/.* { rewrite ^/resource/wa/([\w|-]+)/([\w|-]+)$ /resource/$1/$2.html last; rewrite ^/resource/wa/([\w|-]+)/([\w|-]+)/([\w|-]+)$ /resource/$1/$2.html last; } |
其中/resource/wa/为所有项目所处的统一目录，第二级目录为项目所在目录，第三级对应项目下的某个单页，第四级为可选，且表示某个单页项目下的某个具体 view。
组内现在使用组内自己开发的移动端 SPA 引擎 Cyra，版本为 1.2.x。框架很轻，使用 hash 做路由，然后统一管理各个 view（视图）的状态以及 view 之间跳转。
开发过程中，遇到很多坑都和使用 hash 做路由有关。当然，问题并不在 hash 本身，而是和客户端以及后端 RD 配合中遇到的问题。比如：
综上，考虑升级框架的路由实现方案，使用 History API 代替 hash，并配合 Session Storage 做多页降级，以此来解决上述问题。
为兼容 Cyra 1.x 开发的项目，此次升级仅修改路由的内部实现方式，
