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: 內部服務器錯誤。 這多是因爲內部程序錯誤引發的。