vue2.9＋laravel5.7＋dingo＋jwt 高效安全的前后端分离场景实践教程

前言： 目前市场上，PHP好像主流在作为API开发的形式存在， 如很火的小程序、H5等，自然的，编写可靠、安全的api接口是必不可少的。 由于我目前刚入职没多久，查看了市场上的一些闭源的一些产品。 大多数都具有一个问题，散乱（接口不规范），开放（不安全），耦合度低 当然，这也是为什么喜欢喷PHP的原因， 强调快速开发，且杂乱无章的插入代码，耦合度、复用度低。 由此衍生了众多的垃圾程序员，包括我自己也存在这样的问题

1、 Api的设计

这里，首选 , 为什么 ?

强调HTTP应当以资源为中心，并且规范了资源URI的风格；

规范了HTTP请求动作（PUT，POST等）的使用，具有对应的语义；

遵循REST规范的Web应用将会获得下面好处：

URL具有很强可读性的，具有自描述性；

资源描述与视图的松耦合；

可提供OpenAPI，便于第三方系统集成，提高互操作性；

如果提供无状态的服务接口，可提高应用的水平扩展性；

简而言之，通过RESTful，增加接口代码可读性。可以更方便的通过资源(post | GET 等)来控制我们的接口。 尽管他不是一个标准，但我们应该向他看齐

首先建议大家导读一下以下系列文章

(RESTful API 最佳实践 阮一峰)[http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html]

(Github 的 Restful HTTP API 设计分解)[https://laravel-china.org/courses/laravel-advance-training/5.5/follow-github-to-learn-restful-http-api-design/787#d503f7]

api资源控制，强调动词，我在干什么，我需要怎么干

我认为一套接口应该尽量满足以下几个原则：

安全可靠，高效，易扩展。

简单明了，可读性强，没有歧义。

API 风格统一，调用规则，传入参数和返回数据有统一的标准。

2、dingo Api

在 的场景中，其实自5.5版本迭代之后， 自带的 足以满足我们的需要

dingo Api 目前还没有稳定版本， 建议大家自我斟酌

使用 大概有以下几个好处

版本控制更方便（封装了一系列的方法供你使用） - 不要重复的造轮子

响应设置更加随心所欲

神奇的 （提高耦合度, 复用代码率简直直线上升）

节流设置

异常处理管理

实践的话，当然开始我们的实践之旅啦

导读： https://laravel-china.org/docs/laravel/5.7/installation/2242 |

安装

我们采用的是 的本地环境 | 项目包这里忽略，自行安装

采用 中国镜像

安装包

发布

开始写代码

api.php 【仅供参考】

需安装 composer require liyu/dingo-serializer-switch ，当渲染数据到前端的时候，会默认的加data = {} ， 安装此项东西可以减轻一些前端的麻烦

中间件由于被dingo接管了， 所以如果使用模型绑定的话， 需加入 这个中间件

响应方法

我们这里追求实践，暂时忽略相关的原理性问题

响应生成器

这个觉得是好东西，首先我的目录结构如下

查看 文章的控制器

有没有发现，代码轻量很多？ transform 传递对应的模型，数据 。他会自动根据你对应的 collection 【集合】 或者 item 【单个模型】来返回你所需要的数据

其中 和 需要注意的地方。 【我在这里吃了点亏】

是一个集合，当操作返回的是多个数据的时候使用它， 例如

如果这里使用则会报一个级别的错误

关于 ，必须继承 且 使用

如上面中对于的接口为

那么我们产生的数据如下

对吧，一目了然， 通过 想要什么数据，就拿什么数据， 而且 通过 , 你同时可以在如何地方，重复使用这一套代码。

而无需在进行编辑，或者为了对应某个接口或者要求而去写代码 ， 直接 了事

返回数据也是如此

当我们规定了相关的响应参数的时候， 直接使用 即可

节流设置

当我们需要防止某个接口重复的被使用，例如常见的攻击之类的， 可以有效的预防

在 中 设置

由此， 简单的dingoapi操作完美成功了， 基本上能应付日常的需求， 如更深层次的，可以参考dingapi文档https://laravel-china.org/docs/dingo-api/2.0.0/Installation/1443

文章部分更新【加强版】

关于这一段代码的修改版

如上， 在 中似乎可以找到更好的办法来进行替代他， - findOrFail , 查看官方的api得知，它会抛出一个 ModelNotFoundException 错误。

回到上面， 说到， 由于dingo接管了laravel自带的错误讯息， 我们可以这样使用

如上， 才可以使用我们的 。 但是，在对文章的增删改查中我们发现，大量运用到了检查文章是否存在的代码块， 我们来优化一下代码， 可以这样使用

创建一个中间件

由此，我们的代码将变成这样

怎么样， 爽不爽呢~~， 使用 的原因， 是因为能够更加定制化的看到自己的错误原因。 更加通俗易懂，当然， 也是很好滴