【API】问题总结
本周前两天一直在做API开发时考虑过几个问题?API怎么做分页更便捷、图片操作相关类可以用工具类封装起来(参数可以使用配置类配置起来) 类似的还有文件路径的操作等等
API资源路由
Laravel5.6支持资源路由,它会去掉不必要的 create 和 edit 方法,因为这两个方法只适用于返回 HTML 页面, 如需要生成资源控制器,只需像下面这样在后面添加 --api :
php artisan make:controller API/PostController --api
接口的权限问题
前期由于不增加项目复杂度,没有加入token时效性机制。中间件的作用是过滤用户的请求,比如我们指定一个路由中的某个需要进行身份验证才可以使用。如下:
在构造函数中指定具体方法(下图的意思是除了index方法其他都需要用户登录才可以操作):
API分页问题
你可能会好奇?分页这么简单在Laravel中直接用Paginate不就搞定了吗?但是你不得不面对这样一个问题:参数的格式化。先来简单看看分页的原理:
关键代码如下:
返回结果如下:
参数说明:
currentpage:表示当前页面的页码
data:业务数据
firstpageurl:首页地址
from:获取切片中第一个条目的数量
lastpage:表示最后一页的页码
lastpageurl:最后一页地址
nextpageurl:表示下一页的链接
perpage:表示每一页显示的数据条目
prevpage_url:表示上一页的链接
to:获取切片中最后一个条目的数量
total:表示数据的总页数
需要把这些参数带到调用者那里去才可以正确使用paginate,但是我们的业务参数不得不格式化。而且路径是返回链接是?=page
的形式,不符合restful api。解决方案一:使用 API Resources(大家自行查文档,这里不多说)。解决方案二:在paginate的基础上做重新做修饰。使用API Resourcewo感觉使用起来不够灵活。所以自己定义一个在paginate方法原来的基础上来处理。
项目中经常使用的firstOrNew
我们使用firstOrNew的目的是在数据中查找匹配给定的值的记录,如果没有找到返回一个新的模型实例。有时候没有注意可能把没有建立索引的值也放进去了。这里有两种情况:1.所有列都没有索引,默认就是全表扫面 SQL分析的type为all。2部分列建立了索引,mysql之前的版本一次查询只能使用一个索引,无法同时使用多个索引条件来扫描,如果有多个索引可以使用,Mysql执行计划会进行效率评估,选取效率最高的索引,但是sql执行计划的效率评估也是需要消耗性能的。我们现在使用的是MySQL5.7,如果存在相同的情况,MySQL会进行索引合并(使用多个索引分别进行扫描取出交集运算)。所以在项目中尽量使用索引,能使用单个索引(包括聚合索引)最好。
写下、记下、留下