前面通过表单进行登陆，会为用户创建一个 session 保存在服务器端，session id 保存在 cookie 中，每次访问服务器的时候服务器端从 cookie 中读取 session id 然后找到用户的 session，就能知道当前用户的信息。但是对于移动端来说，传递 cookie 不是很方便，一般都会使用 token 来进行验证。
Token 就是一个字符串(可以使用 uuid)，验证时使用的 token 可以理解为和 session id 的功能差不多:
- 用户申请 token 时，可以把 token 作为 key，用户信息的对象作为 value 保存到 Redis 中，把 token 返回给移动端
- 移动端保存 token，有很多种方式，例如保存到文件中，sqlite 里都可以
- 每次访问的时候把 token 放到请求的 header 中
- 服务器端从 header 中读取 token，然后用 token 作为 key 去 Redis 中去读用户数据
- 如果读取到的用户数据有效，则说明用户是合法的，认证通过，继续访问，否则返回错误，终止请求
使用纯 token 验证，不支持 session，这样的应用一般都是用来提供纯数据服务(应用中没有网页，很多微服务就是这样的)，以下叫 DSA(Data Service Application)，但是数据也是需要后台功能来管理的，大多都会使用 Web 应用，叫 DMA(Data Management Application)，Web 应用需要使用 session，也就是说 DSA 和 DMA 是独立的 2 个应用，不能共存，因为 DSA 中不支持 session，而 DMA 中需要 session。这种设计的好处是 DSA 很轻量级，只关心数据服务，能够降低开发的复杂度，还有其它比如每个服务都很简单，只关注于一个业务功能，每个微服务可以由不同的团队独立开发，微服务是松散耦合的等等。但是也有缺点，比如有可能对资源的访问需要重复实现，例如一个电子图书馆程序，读取图书信息的 API /api/books/{bookId} 在 DSA 中需要实现，在 DMA 中也要提供实现，因为 DMA 中也需要读取图书信息进行管理，就算用分布式服务使用 dubbo 负责服务治理，由 DMA 提供访问数据的逻辑，但是 DSA 和 DMA 里都至少也要各自有个 Controller 来处理这个 URL 吧。
本文的目的，是要实现一个 Web 应用即支持 session，同时又能支持使用 token 进行身份验证时不生成 session:
- 浏览器访问 /api/books/{bookId} 时，从 cookie 中读取 session id 找到对应的 session，获取当前用户，如果没有登陆则跳转到登陆页面进行登陆，登陆成功会创建 session
- 移动端访问 /api/books/{bookId} 时，从 header 中读取 token 找到对应的用户，如果没有 token 或者 token 过期、用户信息无效则返回错误提示未登陆认证(token 可以事先请求保存起来)，整个过程不会产生 session
