关于thinkjs:如何使用-ThinkJS-优雅的编写-RESTful-API

RESTful 是目前比拟支流的一种用来设计和编排服务端 API 的一种标准。在 RESTful API 中，所有的接口操作都被认为是对资源的 CRUD，应用 URI 来示意操作的资源，申请办法示意具体的操作，响应状态码示意操作后果。之前应用 RESTful 的标准写过不少 API 接口，我集体认为它最大的益处就是帮忙咱们更好的去布局整顿接口，如果还是依照以前依据需要来写接口的话接口的复用率不高不说，整个我的项目也会变得十分的芜杂。

文件即路由是 ThinkJS 的一大特色，比方 /user 这个路由等价于 /user/index，会对应到 src/controller/user.js 中的 indexAction 办法。那么就以 /user 这个 API 为例，在 ThinkJS 中要创立 RESTful 格调的 API 须要以下两个步骤：

运行命令 thinkjs controller user -r 会创立路由文件 src/controller/user.js
在 src/config/router.js 中应用自定义路由标记该路由为 RESTful 路由
```
//src/config/router.jsmodule.exports = [  ['/user/:id?', 'rest']];
```

这样咱们就实现了一个 RESTful 路由的初始化，这个资源的所有操作都会被映射成路由文件中对应申请办法的 Action 函数中，例如：

GET /user 获取用户列表，对应 getAction 办法
GET /user/:id 获取某个用户的详细信息，也对应 getAction` 办法
POST /user 增加一位用户，对应 postAction 办法
PUT /user/:id 更新一位用户材料，对应 putAction 办法
DELETE /user/:id 删除一位用户，对应 deleteAction 办法

然而每个 RESTful 路由都须要去 router.js 中写一遍自定义路由未免过于麻烦。所以我写了一个中间件 think-router-rest，只须要在 Controller 文件中应用 _REST 动态属性标记一下就能够将其转换成 RESTful 路由了。

//src/controller/user.jsmodule.exports = class extends think.Controller {  static get _REST() {    return true;  }  getAction() {}  postAction() {}  putAction() {}  deleteAction() {}}

简略的理解了一些入门常识之后，上面我就讲一些我平时开发 RESTful 接口时对我有帮忙的一些知识点，心愿对大家开发我的项目会有所帮忙。

表构造梳理

拿到需要之后千万不要急着先敲键盘，肯定要把表构造整顿好。其实说是表构造，实际上就是对资源的整顿。以 MySQL 为例，个别一类资源就会是一张表，比方 user 用户表，post 文章表等。当你把表列举进去之后那么其实你的 RESTful 接口就曾经七七八八了。比方你有一张 post 文章表，那么之后你的接口必定会有：

GET /post 获取文章列表
GET /post/1 获取 id=1 的文章信息
POST /post 增加文章
PUT /post/1 批改 id=1 的文章信息
DELETE /post/1 删除 id=1 的文章

当然不是所有的事件都这么完满，有时候接口的操作可能形形色色，这种时候咱们就要尽量的去思考接口行为的实质是什么。比如说咱们要迁徙文章给其它用户，这时候你就要思考它其实实质上就是批改 post 文章资源的 user_id 属性，最终还是会映射到 PUT /post/1 接口中来。

想分明有哪些资源能帮忙你更好的创立表，接下来就要想分明资源之间的关系了，它能帮忙你更好的创立表构造。个别资源之间会存在以下几类关系：

一对一：如果一位 user 只能创立一篇 post 文章，则是一对一的关系。在 post 中能够应用 user_id 字段来关联对应的 user 数据，在 user 中也能够应用 post_id 来关联对应的文章数据。
一对多：如果一位 user 能创立多篇 post 文章，则是一对多的关系。在 post 中能够应用 user_id 字段来关联对应的 user 数据。
多对多：如果一位 user 能够创立多篇 post 文章，一篇 post 文章也能够有多位 user，则是多对多的关系。多对多关系没方法通过一个字段来示意，这时候为了形容分明多对多的关系，就须要一张两头表 user_post，用来做 user 和 post 表的关系映射。表外部的 user_id 示意 user 表 ID，post_id 则示意 post 表对应数据 ID。

mysql> DESCRIBE user;+-------+--------------+------+-----+---------+----------------+| Field | Type         | Null | Key | Default | Extra          |+-------+--------------+------+-----+---------+----------------+| id    | int(11)      | NO   | PRI | NULL    | auto_increment || name  | varchar(100) | YES  |     | NULL    |                |+-------+--------------+------+-----+---------+----------------+2 rows in set (0.01 sec)mysql> DESCRIBE post;+-------+---------+------+-----+---------+----------------+| Field | Type    | Null | Key | Default | Extra          |+-------+---------+------+-----+---------+----------------+| id    | int(11) | NO   | PRI | NULL    | auto_increment || title | text    | YES  |     | NULL    |                |+-------+---------+------+-----+---------+----------------+2 rows in set (0.00 sec)mysql> DESCRIBE user_post;+---------+---------+------+-----+---------+----------------+| Field   | Type    | Null | Key | Default | Extra          |+---------+---------+------+-----+---------+----------------+| id      | int(11) | NO   | PRI | NULL    | auto_increment || user_id | int(11) | NO   |     | NULL    |                || post_id | int(11) | NO   |     | NULL    |                |+---------+---------+------+-----+---------+----------------+3 rows in set (0.00 sec)

作为一款约定大于配置的 Web 框架，ThinkJS 默认规定了申请 RESTful 资源的时候，会依据以后资源 URI 找到对应的资源表，比方 GET /post 会找到 post 表。而后再进行查问的之后会进行主动的关联查问。例如当你在模型里标记了 post 和 user 是一对多的关系，且 post 表中存在 user_id 字段（也就是关联表表名 + _id），会主动关联获取到 project 对应的 user 数据。这在进行数据操作的时候会节俭十分多的工作量。

登录登出

当我第一次写 RESTful API 的时候，我就碰到了这个难题，平时大家都是应用 /login, /logout 来示意登录和登出操作的，如何应用资源的模式来表白就成了问题。起初想了下登录操作中波及到的资源其实就是登录后的 Token 凭证，实质上登录就是凭证的创立与获取，登出就是凭证的删除。

GET /token：获取凭证，用来判断是否登录
POST /token：创立凭证，用来进行登录操作
DELETE /token：删除凭证，用来进行登出操作

权限校验

咱们平时写接口逻辑，其实会有很大一部分的工作量是用来做用户申请的解决。包含用户权限的校验和用户参数的校验解决等，这些逻辑其实和主业务场景没有太大的关系。为了将这些逻辑与主业务场景进行解耦，基于 Controller 层之上，ThinkJS 会存在一层 Logic 逻辑校验层。Logic 与 Controller 一一映射，并提供了一些罕用的校验办法，咱们能够将权限校验，参数校验，参数解决等逻辑放在这里，让 Controller 只做真正的业务逻辑。

在 Logic 和 Controller 中，都存在 __before() 魔术办法，以后 Controller 内所有的 Action 执行之前都会先执行 __before() 操作。利用这个个性，咱们能够将一些通用的权限校验逻辑放在这里，比方最平时的登录判断逻辑，这样就不须要在每个中央都做判断了。

//src/logic/base.jsmodule.exports = class extends think.Logic {  async __before() {    //接口 CSRF 校验    if (!this.isCli && !this.isGet) {      const referrer = this.referrer(true);      if (!/^xxx\.com$/.test(referrer)) {        return this.fail('请不要在非其它网站中应用该接口！');      }    }    // 非登录接口须要做登录校验    const userInfo = await this.session('userInfo') || {};    if(think.isEmpty(userInfo) && !/\/(?:token)\.js/.test(this.__filename)) {      return this.ctx.throw(401, 'UnAuthorized');    }  }}//src/logic/user.jsconst Base = require('./base.js');module.exports = class extends Base {}

创立一个 Base 基类，所有的 Logic 通过继承该基类就都能享受到 CSRF 和登录校验了。

问：所有的申请都会实例化类，所以 contructor 实质上也会在所有的 Action 之前执行，那为什么还须要 __before() 魔术办法的存在呢？
答：constructor 构造函数尽管有前置执行的个性，然而无奈在保障程序的状况下执行异步操作。构造函数前是不能应用 async 标记的，而 __before() 是能够的，这也是它存在的起因。

善用继承

在 RESTful API 中，咱们其实会发现很多资源是具备从属关系的。比方一个我的项目下的用户对应的文章，这句话中的三种资源 我的项目，用户 和 文章 就是从属关系。在从属关系中包含权限、数据操作等也都是具备从属关系的。比如说文章属于用户，非该用户的话天然是无奈看到对应的文章的。而用户又从属于我的项目，其它我的项目的人是无奈操作该我的项目下的用户的。这就是所谓的从属关系。

确立了从属关系之后咱们会发现越到上级的资源在对其操作的时候要判断的权限就越多。以方才的例子为例，如果说咱们对我的项目资源进行操作的话，咱们须要判断该用户是否在我的项目中。而如果要对我的项目下的用户文章进行操作的话，除了须要判断用户是否在我的项目中，还须要判断该文章是否是以后用户的。

在这个例子中咱们能够发现：资源关系隶属的话权限校验也会是从属关系，从属关系中级别越深的资源须要判断的权限越多。面向对象语言中，继承是一个比拟重要的性能，它最大的益处就是能帮忙咱们进行逻辑的复用。通过继承，咱们能间接在子资源中复用父资源的校验逻辑，防止重复劳动。

//src/logic/base.jsmodule.exports = class extends think.Logic {  async __before() {    const userInfo = this.session('userInfo') || {};    this.userInfo = this.ctx.state.userInfo = userInfo;    if(think.isEmpty(userInfo)) {      return this.ctx.throw(401);    }  }}//src/logic/project/base.jsconst Base = require('../base.js');module.exports = class extends Base {async __before() {    await super.__before();    const {team_id} = this.get();    const {id: user_id} = this.userInfo;    const permission = await this.model('team_user').where({team_id, user_id}).find();        const {controller} = this.ctx;    // 团队接口中只有普通用户只有权限调用获取邀请链接详细信息和承受邀请链接两个接口    if(controller !== 'team/invitation' && (this.isGet && !this.id)) {      if(think.isEmpty(permission)) {        return this.fail('你没有权限操作该团队');      }    }        this.userInfo.role_id = permission.role_id;  }}//src/logic/project/user/base.jsconst Base = require('../base');module.eports = class extends Base {  async __before() {    await super.__before();        const {role_id} = this.userInfo;    if(!global.EDITOR.is(role_id)) {      return this.fail('你没有权限操作该文章');    }  }}

通过创立三个 Base 基类，咱们将权限校验进行了正当的拆分同时又能保障校验的完整性。同级别的路由只有继承以后层级的 Base 基类就能享受到通用的校验逻辑。

/project 路由对应的 Logic 因为继承了 src/logic/base.js 所以实现了登录校验。
/project/1/user 路由对应的 Logic 因为继承了 src/logic/project/base.js 所以实现了登录校验以及是否在是我的项目成员的校验。
/project/1/user/1/post 路由对应的 Logic 因为继承了 src/logic/project/user/base.js 所以实现了登录校验、我的项目成员校验以及我的项目成员权限的校验。

瞧，套娃就这么简略！

数据库操作

隶属的资源在表构造上也有肯定的反馈。还是以之前的我的项目、用户和文章为例，一般来说你的文章表里会存在 project_id 和 user_id 两个关联字段来示意文章与用户和我的项目资源的关系（简略假如都是一对多的关系）。那么这时候实际上你对我的项目下的文章操作实际上都须要传入 project_id 和 user_id 这两个 WHERE 条件。

ThinkJS 外部应用 think-model 来进行 SQL 数据库操作。它有一个个性是反对链式调用，咱们能够这样写一个查问操作。

//src/controller/project/user/post.jsmodule.exports = class extends think.Controller {  async indexAction() {    const ret = await this.model('post').where({project_id: 1}).where({user_id: 2}).select();    return this.success(ret);  }}

利用这个个性，咱们能够对操作进行优化，在 constructor 的时候将以后 Controller 下的通用 WHERE 条件 project_id 和 user_id 传入。这样咱们在其它的 Action 操作的时候就不必每个都传一变了，同时也肯定躲避了可能会漏传限度条件的危险。

//src/controller/project/user/post.jsmodule.exports = class extends think.Controller {  constructor(ctx) {    super(ctx);    const {project_id, user_id} = this.get();    this.modelInstance = this.model('post').where({project_id, user_id});  }  async getAction() {    const ret = await this.modelInstance.select();    return this.success(ret);  }}

后记

RESTful API 除了以上说的一些个性之外，它对响应状态码、接口的版本也有肯定的标准定义。像 Github 这种 RESTful 实现比拟好的网站还会实现 Hypermedia API 标准，在每个接口中会返回操作其它资源时须要的 RESTful 路由地址，不便调用者进行链式调用。

当然 RESTful 只是实现 API 的一种标准，还有其它的一些实现标准，比方 GraphQL。对于 GraphQL 能够看看之前的文章《GraphQL 根底实际》，这里就不多做补充了。