这半个月断断续续在学习用PHP的ThinkPHP框架开发后端API。现在总结记录一下开发一个接口需要做好哪些事，以此提高开发效率，并且也有不错的扩展性。
一、流程概要
基本是这么一个流程，略过环境搭建：
- 整理清楚有哪些接口
- 设计数据表
- 初步梳理是一对一，一对多，还是多对多
- 编写验证器
- 编写全局异常类（AOP思想）
- 定义路由路径
- 建立控制器类
- 建立模型类
- 用ORM，所以建立和数据表对应的模型类
- 控制器调用模型，模型调用数据库，完成接口编写
二、具体说明
梳理好有哪些接口后，就开始设计数据表：
数据表会随着代码的编写做些调整和改变。
值得注意的一点，当有两张表之间的关系是多对多时，记得设计一张中间表存放两张表各自的id。
设计好数据表后，开始编写一些工具类，有助于提高编写业务代码时的效率。
首先是验证器(validate)。
TP5框架自带验证器类，我们要做的则是继承这个验证器类，然后根据具体的接口做扩展即可。
创建一个验证器基类，把通用的方法放在里面：
goCheck()方法是所有具体验证器都会调用的方法，各个具体验证器只是会重写一些验证规则和验证返回信息而已。
在goCheck()方法里，实例化了Request类。这样做的目的是获取API被调用时，调用方传递的参数。获取到参数后，自然就是对这些参数进行验证了。check()方法会调用各个具体验证器里设置的验证规则函数进行检测。
然后是全局异常类(global exception)。
同样的，TP5框架自带了一个异常类，我们就创建一个异常基类继承它。
随后需要做的则是根据具体的接口重写HTTP状态码，错误消息和错误码即可。
至于错误码的定义，则是自己设计一套规范。
搭建好验证器和全局异常类后，我们只需要在每个接口的函数里面调用他们就行了：
好，至此一些基础的东西就搭建好了，下面开始编写接口代码。
首先定义路由路径:
在route.php里，引入Route类，定义路径即可。路径里的变量用:号+变量名表示，路径里的变量由路径末尾指定的函数接收，这个函数定义在控制器相对应的类里面。
比如id这个变量：
如上图，在控制器里，当拿到调用方通过路由路径传过来的参数后，我们就调用模型，把参数传过去，模型处理具体的数据库调用。
这里也是一个需要注意的点，控制器尽量只做连接的事情，不做具体的操作。
然后，在建立了控制器后，顺理成章，也需要建立对应的模型。
TP5同样自带了Model类，然后我们也定义自己的模型基类，当然也是继承TP5的模型类：
模型基类自然也是定义较为通用的方法。比如上图的例子里，定义了一个返回图片前缀链接的方法，不同的接口但又跟图片调用有关的话，就会用到这个方法来拼接图片URL。
这里也有个注意的点。当我们需要创建全局的变量时，可以在application目录下创建extra目录文件，然后创建setting.php文件，在里面返回一个关联数组即可：
随后的调用如上图模型基类里的prefixImgUrl方法里展示的一样，config函数，参数传入文件名加关联数组的key值，这样就可以获取到了：
回到模型上来，每个接口会有自己的模型类，这个模型类对应一张数据表，比如：
Banner模型类由于是通过模型基类继承了TP5的Model类，我们需要做的就是重写一些属性，来适应这个具体的接口，比如重写$hidden属性，定义这个接口返回的哪些字段我们是要隐藏的。
然后则是ORM的重点之一，调用数据表所对应的模型类。比如items方法里，通过hasMany()这个方法确定了Banner模型和BannerItem模型的关系。然后在getBannerById()方法里，调用了ORM用来操作数据的方法，这是对原生操作数据库语句的封装，然后ORM会返回模型对象，这个对象除了带有数据库数据外，还会带有一些属性和方法，用来操作数据。这是ORM对比原生SQL语句的一个优势。
最后，控制器调用模型的getBannerById()方法，获取到了数据，再作为接口的返回值传递给接口调用者。这样就完成了一次接口的编写。
三、总结
至此做了一个简要的后端API开发流程记录。其中还有很多细节没有提到，只是简略的描述了一个过程，不过这也不是这次记录的主要目的。这次的目的还是对这一周多学习的一个记录。
通过这次学习后端API开发，更加巩固了我对面向对象编程里思想的理解和运用。
通过继承和重写，可以把代码写得更干净简洁。
类，实例，属性，方法，怎么看待他们，然后操作他们，通过这次学习又加深了很多认识。
