yii2 RESTful api的详细使用

什么是RESTful风格的API

对于各类客户端设备与服务端的通讯，咱们每每都经过API为客户端提供数据，提供某种资源。关于RESTful的概念，一查一大推，一两句也解释不清，姑且先按照咱们通俗的理解：在众多风格、众多原则的API中，RESTful就是一套比较优秀的接口调用方式。

Yii2如何实现RESTful风格的API

一、创建单独的应用程序

为了增长程序的可维护性，易操做性，咱们选择新建一套应用程序，这也是为了和前台应用、后台应用区分开操做。有些人要嚷嚷了，为啥非得单独搞一套呢？若是你就单纯的提供个别的几个h5页面的话，那就没有必要了，但事实每每是客户端要升级啊，要增长不一样的版本啊，这就须要咱们不但要后端不只要增长一套单独的应用程序，咱们还要增长各类版本去控制。

在WEB前端（frontend）和后端（backend）的同级目录，新建一个文件夹，命名api,其目录结构以下所示：

├─assets
│      AppAsset.php
├─config
│      bootstrap.php
│      main-local.php
│      main.php
│      params-local.php │ params.php ├─runtime └─web │ index.php ├─assets └─css 

能够看出其目录结构基本上同backend没有其余差别，由于咱们就是拷贝backend项目，只是作了部分优化。

友情提醒，该步骤完成之后，须要修改common\config\bootstrap.php文件，对新建的应用增长alias别名

Yii::setAlias('@api', dirname(dirname(__DIR__)) . '/api'); 

二、为新建的api应用程序美化路由

首先保证你的web服务器开启rewrite规则，细节咱们就不说了，不过这是前提。

接着配置api/config/main.php文件

'components' => [
    // other config 'urlManager' => [ 'enablePrettyUrl' => true, 'showScriptName' => false, 'enableStrictParsing' =>true, 'rules' => [], ] ],

最后只须要在应用入口同级增长.htaccess文件就好，咱们以apache为例

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 

三、利用gii生成测试modules

用了便于演示说明，咱们新建一张数据表goods表，并向其中插入几条数据。

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目录结构应该多个下面这几个目录

│
├─models
│      Goods.php
│
├─modules
│  └─v1
│      │  Module.php
│      │
│      ├─controllers
│      │      DefaultController.php
│      │      GoodsController.php
│      │
│      └─views
│          └─default
│                  index.php

须要说明的是：在生成modules的步骤中，为了使咱们的模块能够访问，不要忘记在main.php配置文件中添加下面的代码

<?php ...... 'modules' => [ 'v1' => [ 'class' => 'api\modules\v1\Module', ], ], ...... 

四、从新配置控制器

为了实现restful风格的api,在yii2中，咱们须要对控制器进行一下改写

<?php namespace api\modules\v1\controllers; use yii\rest\ActiveController; class GoodsController extends ActiveController { public $modelClass = 'api\models\Goods'; } 

五、为Goods配置Url规则

'rules' => [
    [
        'class' => 'yii\rest\UrlRule', 'controller' => ['v1/goods'] ], ] 

六、模拟请求操做

通过上面几个步骤，到此咱们已经为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架构中，网址中只能有名词而不能包含动词，名词又每每与数据表相对应，数据表呢又是一个“集合”，所以该名词每每是复数的形式。

七、关于受权认证

为何须要受权认证？这在通常的操做中是须要的。好比说用户要设置本身的信息。

为了对yii2 restful受权认证说的更清楚，咱们将会以两个两种不一样的方法进行说明。

首先须要开启认证：

假设咱们已经按照第3步建立了包含字段access-token的数据表user，并且利用gii上生成了相应的model和controller

配置main.php文件

'components' => [
    'user' => [ 'identityClass' => 'common\models\User', 'enableAutoLogin' => true, 'enableSession'=>false ], ], 

为控制器配置authenticator行为指定认证方式

<?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方法

public static function findIdentityByAccessToken($token, $type = null) { return static::findOne(['access_token' => $token, 'status' => self::STATUS_ACTIVE]); } 

如此一来，咱们先经过postman模拟不带access-token请求看结果

{
  "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格式的！

八、速率限制

速率限制，该操做彻底也是出于安全考虑，咱们须要限制同一接口某时间段过多的请求。

速率限制默认不启用，用启用速率限制，yii\web\User::identityClass 应该实现yii\filters\RateLimitInterface，也就是说咱们的common\models\User.php须要实现yii\filters\RateLimitInterface接口的三个方法，具体代码可参考：

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中新增长两个字段

1. allowance：剩余的容许的请求数量
2. allowance_updated_at：相应的UNIX时间戳数

在咱们启用了速率限制后，Yii 会自动使用 yii\filters\RateLimiter 为 yii\rest\Controller 配置一个行为过滤器来执行速率限制检查。

如今咱们经过postman请求v1/users再看看结果，会发如今10秒内调用超过5次API接口，咱们会获得状态为429太多请求的异常信息。

{
  "name": "Too Many Requests", "message": "Rate limit exceeded.", "code": 0, "status": 429, "type": "yii\\web\\TooManyRequestsHttpException" } 

九、关于版本

为了兼容历史版本并且考虑向后兼容性，咱们在一开始操做的时候就以URL的方式实现了版本话，这里就再也不进行阐述了。

十、错误处理

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: 内部服务器错误。 这多是因为内部程序错误引发的。