理解Web路由（浅谈先后端路由与先后端渲染）

时间 2019-11-11

标签理解 web 路由浅谈后端渲染栏目 HTML 繁體版

原文原文链接

1.什么是路由?

在Web开发过程当中，常常会遇到『路由』的概念。那么，到底什么是路由？简单来讲，路由就是URL到函数的映射。javascript

路由的概念最开始是由后端提出来的，在之前用模板引擎开发页面的时候，是使用路由返回不一样的页面，php

大体流程能够当作这样：css

（1）浏览器发出请求html

（2）服务器端监听到80端口或者443有请求过来，并解析url路径前端

（3）根据服务器的路由配置，返回相应信息（能够是html文件，json数据，也能够是图片）vue

（4）浏览器根据数据包的content-type来决定如何解析数据html5

简单来讲路由就是用来跟后端服务器进行交互的一种方式，经过不一样的路径来请求不一样的资源，请求不一样的页面是路由的其中一项功能。java

2.router 和 route 的区别

route就是一条路由，它将一个URL路径和一个函数进行映射，例如：node

/users        ->  getAllUsers()
/users/count  ->  getUsersCount()

这就是两条路由，当访问 /users 的时候，会执行 getAllUsers() 函数；当访问 /users/count 的时候，会执行 getUsersCount() 函数。react

而 router 能够理解为一个容器，或者说一种机制，它管理了一组 route。简单来讲，route 只是进行了URL和函数的映射，而在当接收到一个URL以后，去路由映射表中查找相应的函数，这个过程是由 router 来处理的。一句话归纳就是 "The router routes you to a route"。

3.服务端路由

对于服务器来讲，当接收到客户端发来的HTTP请求，会根据请求的URL，来找到相应的映射函数，而后执行该函数，并将函数的返回值发送给客户端。对于最简单的静态资源服务器，能够认为，全部URL的映射函数就是一个文件读取操做。对于动态资源，映射函数多是一个数据库读取操做，也多是进行一些数据的处理，等等。

以 Express 为例:

app.get('/', (req, res) => { res.sendFile('index') }) app.get('/users', (req, res) => { db.queryAllUsers() .then(data => res.send(data)) })

这里定义了两条路由：

当访问 / 的时候，会返回 index 页面
当访问 /users 的时候，会从数据库中取出全部用户数据并返回

不只仅是URL 在 router 匹配 route 的过程当中，不只会根据URL来匹配，还会根据请求的方法来看是否匹配。例如上面的例子，若是经过 POST 方法来访问 /users，就会找不到正确的路由。

4.客户端路由

对于客户端（一般为浏览器）来讲，路由的映射函数一般是进行一些DOM的显示和隐藏操做。这样，当访问不一样的路径的时候，会显示不一样的页面组件。客户端路由最多见的有如下两种实现方案：

(1)基于Hash

咱们知道，URL中 # 及其后面的部分为 hash。例如：

const url = require('url')
var a = url.parse('http://example.com/#/foo/bar')
console.log(a.hash)
// => #/foo/bar

hash仅仅是客户端的一个状态，也就是说，当向服务器发请求的时候，hash部分并不会发过去。

经过监听 window 对象的 hashChange 事件，能够实现简单的路由。例如：即根据哈希值的不一样显示不一样的内容

window.onhashchange = function() {
  var hash = window.location.hash
  var path = hash.substring(1) //截取指定下标直接的字符，这是从下标1开始到结尾

  switch (path) {
    case '/':
      showHome()
      break
    case '/users':
      showUsersList()
      break
    default:
      show404NotFound()
  }
}

(2)基于History API

经过HTML5 History API能够在不刷新页面的状况下，直接改变当前URL。详细用法能够参考：

咱们能够经过监听 window 对象的 popstate 事件，来实现简单的路由：

window.onpopstate = function() {
  var path = window.location.pathname

  switch (path) {
    case '/':
      showHome()
      break
    case '/users':
      showUsersList()
      break
    default:
      show404NotFound()
  }
}

可是这种方法只能捕获前进或后退事件，没法捕获 pushState 和 replaceState，一种最简单的解决方法是替换 pushState 方法，例如：

var pushState = history.pushState
history.pushState = function() {
  pushState.apply(history, arguments)

  // emit a event or just run a callback
  emitEventOrRunCallback()
}

不过，最好的方法仍是使用实现好的 history 库。

(3)两种方法的比较

总的来讲，基于Hash的路由，兼容性更好；基于History API的路由，更加直观和正式。可是，有一点很大的区别是，基于Hash的路由不须要对服务器作改动，基于History API的路由须要对服务器作一些改造。下面来详细分析。假设服务器只有以下文件（script.js被index.html所引用）：

/-
 |- index.html |- script.js

基于Hash的路径有：

http://example.com/ http://example.com/#/foobar

基于History API的路径有：

http://example.com/ http://example.com/foobar

当直接访问 / 的时候，二者的行为是一致的，都是返回了 index.html 文件。

当从 / 跳转到 /#/foobar 或者 /foobar 的时候，也都是正常的，由于此时已经加载了页面以及脚本文件，因此路由跳转正常。

当直接访问 /#/foobar 的时候，实际上向服务器发起的请求是 /，所以会首先加载页面及脚本文件，接下来脚本执行路由跳转，一切正常。

当直接访问 /foobar 的时候，实际上向服务器发起的请求也是 /foobar，然而服务器端只能匹配 / 而没法匹配 /foobar，所以会出现404错误。

所以若是使用了基于History API的路由，须要改造服务器端，使得访问 /foobar 的时候也能返回 index.html 文件，这样当浏览器加载了页面及脚本以后，就能进行路由跳转了。

5.动态路由

上面提到的例子都是静态路由，也就是说，路径都是固定的。可是有时候咱们须要在路径中传入参数，例如获取某个用户的信息，咱们不可能为每一个用户建立一条路由，而是在经过捕获路径中的参数（例如用户id）来实现。

例如在 Express 中：

app.get('/user/:id', (req, res, next) => { // ... ... })

在 Flask 中：

@app.route('/user/<user_id>') def get_user_info(user_id): pass

6.严格路由

在不少状况下，会遇到 /foobar 和 /foobar/ 的状况，它们看起来很是相似，然而实际上有所区别，具体的行为也是视服务器设置而定。

在 Flask的文档中，提到，末尾有斜线的路径，类比于文件系统的一个目录；末尾没有斜线的路径，类比于一个文件。所以访问 /foobar 的时候，可能会重定向到 /foobar/，而反过来则不会。

若是使用的是 Express，默认这二者是同样的，也能够经过 app.set 来设置 strict routing，来区别对待这两种状况。

什么是路由？

在Web开发过程当中，常常会遇到『路由』的概念。那么，到底什么是路由？简单来讲，路由就是URL到函数的映射。

访问的URL会映射到相应的函数里（这个函数是广义的，能够是前端的函数也能够是后端的函数），而后由相应的函数来决定返回给这个URL什么东西。路由就是在作一个匹配的工做。

从后端路由讲起

在web开发早期的「刀耕火种」年代里，一直是后端路由占据主导地位。无论是php，仍是jsp、asp，用户能经过URL访问到的页面，大可能是经过后端路由匹配以后再返回给浏览器的。经典面试题，「你从浏览器地址栏里输入www.baidu.com到你看到网页这个过程当中经历了什么」其实讲的也是这个道理。

在web后端，无论是什么语言的后端框架，都会有一个专门开辟出来的路由模块或者路由区域，用来匹配用户给出的URL地址，以及一些表单提交、ajax请求的地址。一般遇到没法匹配的路由，后端将会返回一个404状态码。这也是咱们常说的404 NOT FOUND的由来。

URL 与 Methods

若是你关注RESTful API，那么将会很熟悉下面四种发起请求的类型：GET，POST，PUT，DELETE。

它们分别对应四种基本操做：GET用来获取资源，POST用来新建资源（也能够用于更新资源），PUT用来更新资源，DELETE用来删除资源。——来自阮一峰《理解RESTful架构》

虽然上面说的是RESTful API，可是实际上咱们在地址栏输入一个URL，并回车的时候，是以GET请求发出去的。这也体现了，URL地址和请求的method也应该是一一对应。下面给出一个例子：

router.post('/user/:id', addUser)

假如个人后端路由配置里只有这一句路由。那么我经过浏览器里访问：http://xxx.com/user/123的话是没法访问到的，也会返回一个404。由于后端只配了一个post方法的路由。若是要接受这个请求，那么必须有以下的路由：

router.get('/user/:id', getUser) // 配置get路由 router.post('/user/:id', addUser)

后端路由与服务端渲染

前面说了，「刀耕火种」的年代里，网页一般是经过后端路由直接输出给客户端浏览器的。也就是网页的html通常是在后端服务器里经过模板引擎渲染好再交给前端的。至于一些其余的效果，是经过预先写在页面里的jQuery、Bootstrap等常见的前端框架去负责的。

若是你说有些网站已是经过ajax去实现的页面，好比gmail，好比qq邮箱。那么你要注意到哪怕是这些页面，它们页面的「龙骨」也并不是是所有经过ajax去实现的，依然仍是后端直出——这也就是咱们如今又老生常谈的服务端渲染。

服务端渲染的好处有不少，好比对于SEO友好，一些对安全性要求高的页面采用服务端渲染是更保险的。而在当时尚未node.js的年代，为了良好地构建前端页面，都是经过服务端语言对应的模板引擎来实现动态网页、页面结构的组织、组件的复用。好比Laravel的blade，用在Django上的jinja2，用在Struts的jsp等等。实际上到现在，一门后端语言想要能实现本身的web功能，都须要有本身对应的模板引擎。

node.js诞生以后，前端拥有本身的后端渲染的模板引擎也成为了现实。常见的好比pug、ejs、nunjucks等。这些模板引擎搭配Express、Koa等后端框架也在一开始风靡一时

不过在这个过程当中，随着web应用的开发愈来愈复杂，单纯服务端渲染的问题开始慢慢的暴露出来了——耦合性太强了，jQuery时代的页面很差维护，页面切换白屏严重等等。耦合性问题虽然能经过良好的代码结构、规范来解决，不过jQuery时代的页面很差维护这是有目共睹的，全局变量满天飞，代码入侵性过高。后续的维护一般是在给前面的代码打补丁。而页面切换的白屏问题虽然能够经过ajax、或者iframe等来解决，可是在实现上就麻烦了——进一步增长了可维护的难度

因而，咱们开始进入了前端路由的时代。

过渡到前端路由

前端路由——顾名思义，页面跳转的URL规则匹配由前端来控制。而前端路由主要是有两种显示方式：

带有hash的前端路由，优势是兼容性高。缺点是URL带有#号很差看
不带hash的前端路由，优势是URL不带#号，好看。缺点是既须要浏览器支持也须要后端服务器支持

前端路由应用最普遍的例子就是当今的SPA的web项目。无论是Vue、React仍是Angular的页面工程，都离不开相应配套的router工具。前端路由带来的最明显的好处就是，地址栏URL的跳转不会白屏了——这也得益于前端渲染带来的好处。

前端路由与前端渲染

讲前端路由就不能不说前端渲染。我以Vue项目为例。若是你是用官方的vue-cli搭配webpack模板构建的项目，你有没有想过你的浏览器拿到的html是什么样的？是你页面长的那样有button有form的样子么？我想不是的。在生产模式下，你看看构建出来的index.html长什么样：

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Vue</title> </head> <body> <div id="app"></div> <script type="text/javascript" src="xxxx.xxx.js"></script> <script type="text/javascript" src="yyyy.yyy.js"></script> <script type="text/javascript" src="zzzz.zzz.js"></script> </body> </html>

一般长上面这个样子。能够看到，这个其实就是你的浏览器从服务端拿到的html。这里面空荡荡的只有一个 <div id="app"></div>这个入口的div以及下面配套的一系列js文件。因此你看到的页面实际上是经过那些js渲染出来的。这也是咱们常说的前端渲染。

前端渲染把渲染的任务交给了浏览器，经过客户端的算力来解决页面的构建，这个很大程度上缓解了服务端的压力。并且配合前端路由，无缝的页面切换体验天然是对用户友好的。不过带来的坏处就是对SEO不友好，毕竟搜索引擎的爬虫只能爬到上面那样的html，对浏览器的版本也会有相应的要求。

须要明确的是，只要在浏览器地址栏输入URL再回车，是必定会去后端服务器请求一次的。而若是是在页面里经过点击按钮等操做，利用router库的api来进行的URL更新是不会去后端服务器请求的。

Hash模式

hash模式利用的是浏览器不会对#号后面的路径对服务端发起路由请求。也即在浏览器里输入以下这两个地址：http://localhost/#/user/1和http://localhost/其实到服务端都是去请求http://localhost这个页面的内容。

而前端的router库经过捕捉#号后面的参数、地址，来告诉前端库（好比Vue）渲染对应的页面。这样，无论是咱们在浏览器的地址栏输入，或者是页面里经过router的api进行的跳转，都是同样的跳转逻辑。因此这个模式是不须要后端配置其余逻辑的，后台只要给前端返回http://localhost对应的html，剩下具体是哪一个页面，就由前端路由去判断即可。

History模式

不带#号的路由，也就是咱们一般能见到的URL形式。router库要实现这个功能通常都是经过HTML5提供的history这个api。好比history.pushState()能够向浏览器地址栏push一个URL，而这个URL是不会向后端发起请求的！经过这个特性，便能很方便地实现漂亮的URL。不过须要注意的是，这个api对于IE9及其如下版本浏览器是不支持的，IE10开始支持，因此对于浏览器版本是有要求的。vue-router会检测浏览器版本，当没法启用history模式的时候会自动降级为hash模式

上面说了，你在页面里的跳转，一般是经过router的api去进行的跳转，router的api调用的一般是history.pushState()这个api，因此跟后端没什么关系。可是一旦你从浏览器地址栏里输入一个地址，好比http://localhost/user/1,这个URL是会向后端发起一个get请求的。后端路由表里若是没有配置相应的路由，那么天然就会返回一个404了！这也就是不少朋友在生产模式遇到404页面的缘由

那么不少人会问了，那为何我在开发模式下没问题呢？那是由于vue-cli在开发模式下帮你启动的那个express开发服务器帮你作了这方面的配置。理论上在开发模式下原本也是须要配置服务端的，只不过vue-cli都帮你配置好了，因此你就不用手动配置了。

那么该如何配置呢？其实在生产模式下配置也很简单，参考vue-router给出的配置例子。一个原则就是，在全部后端路由规则的最后，配置一个规则，若是前面其余路由规则都不匹配的状况下，就执行这个规则——把构建好的那个index.html返回给前端。这样就解决了后端路由抛出的404的问题了，由于只要你输入了http://localhost/user/1这地址，那么因为后端其余路由都不匹配，那么就会返回给浏览器index.html。

浏览器拿到这个html以后，router库就开始工做，开始获取地址栏的URL信息，而后再告诉前端库（好比Vue）渲染对应的页面。到这一步就跟hash模式是相似的了。

固然，因为后端没法抛出404的页面错误，404的URL规则天然是交给前端路由来决定了。你能够本身在前端路由里决定什么URL都不匹配的404页面应该显示什么。设置默认路由

前端路由与服务端渲染

虽然前端渲染有诸多好处，不过SEO的问题，仍是比较突出的。因此react、vue等框架在后来也在服务端渲染上作着本身的努力。基于前端库的服务端渲染跟之前基于后端语言的服务端渲染又有所不一样。前端框架的服务端渲染大多依然采用的是前端路由，而且因为引入了状态统1、vnode等等概念，它们的服务端渲染对服务器的性能要求比php等语言基于的字符串填充的模板引擎渲染对于服务器的性能要求高得多。因此在这方面不只是框架自己在不断改进算法、优化，服务端的性能也必需要有所提高。当初掘金换成SSR的时候也遇到了对应的性能问题，就是这个缘由。

固然在两者之间，也出现了预渲染的概念。也即先在服务端构建出一部分静态的html文件，用于直出浏览器。而后剩下的页面再经过经常使用的前端渲染来实现。一般咱们能够把首页采用预渲染的方式。这个的好处是明显的，兼顾了SEO和服务器的性能要求。不过它没法作到全站SEO，生产构建阶段耗时也会有所提升，这也是遗憾所在。

关于预渲染，能够考虑使用prerender-spa-plugin这个webapck的插件，它的3.x版本开始使用puppeteer来构建html文件了。

先后端分离

得益于前端路由和现代前端框架的完整的先后端渲染能力，跟页面渲染、组织、组件相关的东西，后端终于能够不用再参与了。

先后端分离的开发模式也逐渐开始普及。前端开始更加注重页面开发的工程化、自动化，然后端则更专一于api的提供和数据库的保障。代码层面上耦合度也进一步下降，分工也更加明确。咱们也摆脱了当初「刀耕火种」的web开发年代。

实列：使用Vue 和 Flask中建立单页面应用去除导航栏中的#号

Vue项目去掉地址栏中的#号，最经常使用的方式就是在路由中使用 history 模式，存在的问题与缘由如上文所述，HTML5的History-Mode在Vue-router中须要配置Web服务器的重定向，将全部路径指向index.html

以Flask建立的 web server 为例，作法很简单，将现有路由修改成如下：

@app.route('/', defaults={'path': ''}) @app.route('/<path:path>') def catch_all(path): return render_template("index.html")

如今输入网址localhost:5000/xxxx 都将从新定向到index.html和vue-router将处理路由。

转载 https://my.oschina.net/u/1778998/blog/3069956

参考：使用 Vue.js 和 Flask 来构建一个单页的App