最近用 Laravel 写了一段时间的 API,总结一下自己的心得吧。
Route::prefix('v1')->group(function () {
// more
});
一个简单的接口示例
jwt-auth
时有疑问,Laravel自带的token验证使用的是数据库api_token字段验证,而不见jwt-auth
需要这个
QAQ
php artisan jwt:secret
生成了秘钥api
的路由Route::apiResource()
,一条更比五条强可以使用控制器自带的表单验证,更推荐使用 表单类,能分离都分离出去,控制器不要处理太多事情。 能分离的代码都不要吝啬~~~
--collection
的格式总是转不过来,后来直接放弃了Resources
Resources::collection()
发现,特别好用 >_<Laravel
处理得太好了条件关联
当时在 laravel-china 看到的这个帖子,然后觉得这个方式不错,所以自己也这样子,使用基类的方法统一响应输出。
异常算是一大手笔了,处理好异常,可以让你的代码优雅很多。
\App\Exceptions\Handler::render
方法可以捕获到很多有用的异常,例如,我的代码是这样写的:
UnauthorizedHttpException
这个是捕获jwt
异常
ValidationException
这个是表单异常,捕获之后,表单错误消息可以很好的格式化,
ModelNotFoundException
这个是模型找不到的异常,捕获之后,可以直接在控制器直接这样
// 未捕获之前的写法
public function show($id)
{
$user = User::find($id);
if (! $user) {
}
// do something
}
// 现在
public function show($id)
{
$user = User::findOrFail($id);
}
// 甚至这样
public function show(User $user)
{
// do something
}
NotFoundHttpException
404 路由找不到的异常,没什么好说的了
MethodNotAllowedHttpException
这个是方法不对应,比如你是get路由,却post请求swagger-ui
+swagger-edit
dist
目录的东西(其他可以删除了)dist
目录的东西和根目录的index.html
swagger-editor
的index.html
改成了edit.html
,然后把这两个东西整合到同一个目录(记得修改css,js的位置)api.json
,api.yaml
大概就和图中差不多api.json
的位置
edit.html
可以书写文档
index.html
可以查看文档edit.html
写好之后,导出json
,然后粘贴到api.json
文件
api.yaml
,因为清楚缓存之后,下次访问时会消失php artisan api:auth
工作和API开发有关,用到其他有经验了再回来补补。
ps:用错账号发了,用这个补一下
1
johnnie502 2018-03-02 04:21:47 +08:00
为啥要用 Laravel,这种场景是属于 Lumen 的
|
2
tSQghkfhTtQt9mtd 2018-03-02 11:16:19 +08:00 via Android
手表笑喷🤣
|
3
DavidNineRoc OP @johnnie502 lumen 有很多功能没有,表单分离验证,数据转换,laravel 官方文档都有 apiResource 路由,所以开发 API 妥妥的,何必省这点性能呢。玩 lumen 想用 laravel 的某些功能时,总想用什么包,或者怎么写才能实现 laravel 的一些功能,所以,花点钱买好的服务器。
|
4
DavidNineRoc OP @liwanglin12 需要买一个吗?童叟无欺
|
5
carlclone 2018-03-02 12:40:00 +08:00
你需要 Laravel Passport , dingo api , JWT
|
6
Jarvix 2018-03-02 14:30:45 +08:00
make
|
7
DavidNineRoc OP @carlclone passport 得看应用场景,我觉得我完全不需要,dingo api 我觉得 lv-5.5 已经有很多功能满足了我的需求,重要的部分验证,数据转换,文档 我都觉已经足够了。
jwt 我又写了,用的 jwt-auth,dingo 内置也是用这个,我单独使用而已 |
8
z5864703 2018-03-05 10:14:20 +08:00
异常处理里面引入控制器来做资源返回?这样处理方式不太好吧
|
9
DavidNineRoc OP @z5864703 主要是为了统一处理响应,而不是直接使用 `response()`
|
10
z5864703 2018-03-05 14:03:17 +08:00
@DavidNineRoc 那用 trait 就好了
|
11
DavidNineRoc OP @z5864703 trait 是无法实例化的。
|
12
z5864703 2018-03-05 17:37:55 +08:00
@DavidNineRoc 为什么要实例化...感觉你不清楚 trait 是干嘛用的...
|
13
DavidNineRoc OP @z5864703 无力吐槽了,是你问我用 trait 就好了,而我告诉你 trait 无法实例化。是因为我的 ApiController 的方法来自于 trait,我这样说可否讲清楚一点了吗?
而且你肯定没有看源码,我并不是返回 ApiController,而是通过内部的 toJson()。好吧是我没说清楚。 https://github.com/DavidNineRoc/laravel-api-helper/blob/master/src/Services/ResponseServe.tpl#L126-L134 |
14
z5864703 2018-03-07 10:17:13 +08:00
@DavidNineRoc 那这更有问题了,ApiController 的方法来源于写的一个 trait,那异常这里直接 use 这个 trait 就好了,还得中间再耦合一个控制器进来,不是多此一举么。和能不能实不实例化有关系么?所以我说你不清楚 trait 干嘛用的,你现在描述的和你的源码更证明了这个观点。。。
|
15
DavidNineRoc OP @z5864703 异常做异常该做的事,为什么返回做 json 响应呢?我使用 ApiController 是因为:当以后我改变了 ApiController 里面的代码,比如响应状态码,现在是 200 是成功,我以后要用 0 做为成功,而我用 ApiController 统一调用,以后不需要懂异常的代码
|