什么是restful风格的api
对于各种客户端设备与服务端的通信,我们往往都通过api为客户端提供数据,提供某种资源。关于restful的概念,一查一大推,一两句也解释不清,姑且先按照我们通俗的理解:在众多风格、众多原则的api中,restful就是一套比较优秀的接口调用方式。
yii2如何实现restful风格的api
1、建立单独的应用程序
为了增加程序的可维护性,易操作性,我们选择新建一套应用程序,这也是为了和前台应用、后台应用区分开操作。有些人要嚷嚷了,为啥非得单独搞一套呢?如果你就单纯的提供个别的几个h5页面的话,那就没有必要了,但事实往往是客户端要升级啊,要增加不同的版本啊,这就需要我们不但要后端不仅要增加一套单独的应用程序,我们还要增加各种版本去控制。
在web前端(frontend)和后端(backend)的同级目录,新建一个文件夹,命名api,其目录结构如下所示:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
├─assets │ appasset.php ├─config │ bootstrap.php │ main-local.php │ main.php │ params-local.php │ params.php ├─runtime └─web │ index.php ├─assets └─css |
可以看出其目录结构基本上同backend没有其他差异,因为我们就是拷贝backend项目,只是做了部分优化。
2、为新建的api应用程序美化路由
首先保证你的web服务器开启rewrite规则,细节我们就不说了,不过这是前提。
接着配置api/config/main.php文件
1
2
3
4
5
6
7
8
9
|
'components' => [ // other config 'urlmanager' => [ 'enableprettyurl' => true, 'showscriptname' => false, 'enablestrictparsing' =>true, 'rules' => [], ] ], |
最后只需要在应用入口同级增加.htaccess文件就好,我们以apache为例
1
2
3
4
5
6
7
8
9
10
|
options +followsymlinks indexignore */* rewriteengine on # if a directory or a file exists, use it directly rewritecond %{request_filename} !-f rewritecond %{request_filename} !-d # otherwise forward it to index.php rewriterule . index.php rewriterule \.svn\/ /404.html rewriterule \.git\/ /404.html |
3、利用gii生成测试modules
用了便于演示说明,我们新建一张数据表goods表,并向其中插入几条数据。
1
2
3
4
5
6
7
8
9
10
|
create table `goods` ( `id` int(11) not null auto_increment, `name` varchar(100) not null default '' , primary key (`id`) ) engine=innodb default charset=utf8; insert into `goods` values ( '1' , '11111' ); insert into `goods` values ( '2' , '22222' ); insert into `goods` values ( '3' , '333' ); insert into `goods` values ( '4' , '444' ); insert into `goods` values ( '5' , '555' ); |
接着我们先利用gii生成modules后,再利用gii模块,按照下图中生成goods信息
现在,我们的api目录结构应该多个下面这几个目录
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
│ ├─models │ goods.php │ ├─modules │ └─v1 │ │ module.php │ │ │ ├─controllers │ │ defaultcontroller.php │ │ goodscontroller.php │ │ │ └─views │ └─ default │ index.php |
4、重新配置控制器
为了实现restful风格的api,在yii2中,我们需要对控制器进行一下改写
1
2
3
4
5
6
7
|
<?php namespace api\modules\v1\controllers; use yii\rest\activecontroller; class goodscontroller extends activecontroller { public $modelclass = 'api\models\goods' ; } |
5、为goods配置url规则
1
2
3
4
5
6
|
'rules' => [ [ 'class' => 'yii\rest\urlrule' , 'controller' => [ 'v1/goods' ] ], ] |
6、模拟请求操作
经过上面几个步骤,到此我们已经为goods成功创建了满足restful风格的api了。为了更好更方便的演示,我们借助工具postman进行模拟请求。
为了见证一下我们的操作,我们用postman请求一下get /v1/goods看看结果如何:
从上面截图中可以清楚的看到,get /v1/goods 已经能够很方便的获取我们表中的数据了。
当然,yii2还对该api封装了如下操作:
get /users: 逐页列出所有用户
head /users: 显示用户列表的概要信息
post /users: 创建一个新用户
get /users/123: 返回用户 123 的详细信息
head /users/123: 显示用户 123 的概述信息
patch /users/123 and put /users/123: 更新用户123
delete /users/123: 删除用户123
options /users: 显示关于末端 /users 支持的动词
options /users/123: 显示有关末端 /users/123 支持的动词
不信的话我们可以利用postman发送一个post请求到/v1/goods,我们会发现成功创建了一个新的商品。
需要提醒的是,操作中还请细心且注意:
如果你的控制器末端不是复数(比如是blog非blogs)请保证请求的时候是复数!这是因为在restful架构中,网址中只能有名词而不能包含动词,名词又往往与数据表相对应,数据表呢又是一个“集合”,因此该名词往往是复数的形式。
7、关于授权认证
为什么需要授权认证?这在一般的操作中是需要的。比如说用户要设置自己的信息。
为了对yii2 restful授权认证说的更清楚,我们将会以两个两种不同的方法进行说明。
首先需要开启认证:
假设我们已经按照第3步创建了包含字段access-token的数据表user,而且利用gii上生成了相应的model和controller
配置main.php文件
1
2
3
4
5
6
7
|
'components' => [ 'user' => [ 'identityclass' => 'common\models\user' , 'enableautologin' => true, 'enablesession' =>false ], ], |
为控制器配置authenticator行为指定认证方式
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
<?php namespace api\modules\v1\controllers; use yii\rest\activecontroller; use yii\helpers\arrayhelper; use yii\filters\auth\queryparamauth; class usercontroller extends activecontroller { public $modelclass = 'api\models\user' ; public function behaviors() { return arrayhelper::merge (parent::behaviors(), [ 'authenticator' => [ 'class' => queryparamauth::classname() ] ] ); } } |
最后我们还需要在identityclass中实现findidentitybyaccesstoken方法
1
2
3
4
|
public static function findidentitybyaccesstoken( $token , $type = null) { return static ::findone([ 'access_token' => $token , 'status' => self::status_active]); } |
如此一来,我们先通过postman模拟不带access-token请求看结果
1
2
3
4
5
6
7
|
{ "name" : "unauthorized" , "message" : "you are requesting with an invalid credential." , "code" : 0, "status" : 401, "type" : "yii\\web\\unauthorizedhttpexception" } |
提示401 我们没有权限访问!
我们在请求的链接上携带正确的access-token,认证通过后,控制器会再继续执行其他检查(频率限制、操作权限等),才可以返回正确的用户信息。
需要提醒的是:通过url的形式对access-token传递存在一定的风险,有可能会造成数据的泄漏!一般而言,access-token需要放到http头中进行传递!除非客户端的请求是jsonp格式的!
8、速率限制
速率限制,该操作完全也是出于安全考虑,我们需要限制同一接口某时间段过多的请求。
速率限制默认不启用,用启用速率限制,yii\web\user::identityclass 应该实现yii\filters\ratelimitinterface,也就是说我们的common\models\user.php需要实现yii\filters\ratelimitinterface接口的三个方法,具体代码可参考:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
use yii\filters\ratelimitinterface; use yii\web\identityinterface; class user extends activerecord implements identityinterface, ratelimitinterface { // other code ...... // 返回某一时间允许请求的最大数量,比如设置10秒内最多5次请求(小数量方便我们模拟测试) public function getratelimit( $request , $action ){ return [5, 10]; } // 回剩余的允许的请求和相应的unix时间戳数 当最后一次速率限制检查时 public function loadallowance( $request , $action ){ return [ $this ->allowance, $this ->allowance_updated_at]; } // 保存允许剩余的请求数和当前的unix时间戳 public function saveallowance( $request , $action , $allowance , $timestamp ){ $this ->allowance = $allowance ; $this ->allowance_updated_at = $timestamp ; $this ->save(); } } |
需要注意的是,你仍然需要在数据表user中新增加两个字段
allowance:剩余的允许的请求数量
allowance_updated_at:相应的unix时间戳数
在我们启用了速率限制后,yii 会自动使用 yii\filters\ratelimiter 为 yii\rest\controller 配置一个行为过滤器来执行速率限制检查。
现在我们通过postman请求v1/users再看看结果,会发现在10秒内调用超过5次api接口,我们会得到状态为429太多请求的异常信息。
1
2
3
4
5
6
7
|
{ "name" : "too many requests" , "message" : "rate limit exceeded." , "code" : 0, "status" : 429, "type" : "yii\\web\\toomanyrequestshttpexception" } |
9、关于版本
为了兼容历史版本而且考虑向后兼容性,我们在一开始操作的时候就以url的方式实现了版本话,这里就不再进行阐述了。
10、错误处理
yii的rest框架的http状态代码可参考如下就好,没啥好说的
200: ok。一切正常。
201: 响应 post 请求时成功创建一个资源。location header 包含的url指向新创建的资源。
204: 该请求被成功处理,响应不包含正文内容 (类似 delete 请求)。
304: 资源没有被修改。可以使用缓存的版本。
400: 错误的请求。可能通过用户方面的多种原因引起的,例如在请求体内有无效的json 数据,无效的操作参数,等等。
401: 验证失败。
403: 已经经过身份验证的用户不允许访问指定的 api 末端。
404: 所请求的资源不存在。
405: 不被允许的方法。 请检查 allow header 允许的http方法。
415: 不支持的媒体类型。 所请求的内容类型或版本号是无效的。
422: 数据验证失败 (例如,响应一个 post 请求)。 请检查响应体内详细的错误消息。
429: 请求过多。 由于限速请求被拒绝。
500: 内部服务器错误。 这可能是由于内部程序错误引起的。