Yii2 RESTful中api的使用及開發(fā)實(shí)例詳解
什么是RESTful風(fēng)格的API
對于各種客戶端設(shè)備與服務(wù)端的通信,我們往往都通過API為客戶端提供數(shù)據(jù),提供某種資源。關(guān)于RESTful的概念,一查一大推,一兩句也解釋不清,姑且先按照我們通俗的理解:在眾多風(fēng)格、眾多原則的API中,RESTful就是一套比較優(yōu)秀的接口調(diào)用方式。
Yii2如何實(shí)現(xiàn)RESTful風(fēng)格的API
1、建立單獨(dú)的應(yīng)用程序
為了增加程序的可維護(hù)性,易操作性,我們選擇新建一套應(yīng)用程序,這也是為了和前臺應(yīng)用、后臺應(yīng)用區(qū)分開操作。有些人要嚷嚷了,為啥非得單獨(dú)搞一套呢?如果你就單純的提供個(gè)別的幾個(gè)h5頁面的話,那就沒有必要了,但事實(shí)往往是客戶端要升級啊,要增加不同的版本啊,這就需要我們不但要后端不僅要增加一套單獨(dú)的應(yīng)用程序,我們還要增加各種版本去控制。
在WEB前端(frontend)和后端(backend)的同級目錄,新建一個(gè)文件夾,命名api,其目錄結(jié)構(gòu)如下所示:
├─assets │ AppAsset.php ├─config │ bootstrap.php │ main-local.php │ main.php │ params-local.php │ params.php ├─runtime └─web │ index.php ├─assets └─css
可以看出其目錄結(jié)構(gòu)基本上同backend沒有其他差異,因?yàn)槲覀兙褪强截恇ackend項(xiàng)目,只是做了部分優(yōu)化。
2、為新建的api應(yīng)用程序美化路由
首先保證你的web服務(wù)器開啟rewrite規(guī)則,細(xì)節(jié)我們就不說了,不過這是前提。
接著配置api/config/main.php文件
'components' => [ // other config 'urlManager' => [ 'enablePrettyUrl' => true, 'showScriptName' => false, 'enableStrictParsing' =>true, 'rules' => [], ] ],
最后只需要在應(yīng)用入口同級增加.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
3、利用gii生成測試modules
用了便于演示說明,我們新建一張數(shù)據(jù)表goods表,并向其中插入幾條數(shù)據(jù)。
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信息
現(xiàn)在,我們的api目錄結(jié)構(gòu)應(yīng)該多個(gè)下面這幾個(gè)目錄
│ ├─models │ Goods.php │ ├─modules │ └─v1 │ │ Module.php │ │ │ ├─controllers │ │ DefaultController.php │ │ GoodsController.php │ │ │ └─views │ └─default │ index.php
4、重新配置控制器
為了實(shí)現(xiàn)restful風(fēng)格的api,在yii2中,我們需要對控制器進(jìn)行一下改寫
<?php namespace api\modules\v1\controllers; use yii\rest\ActiveController; class GoodsController extends ActiveController { public $modelClass = 'api\models\Goods'; }
5、為Goods配置Url規(guī)則
'rules' => [ [ 'class' => 'yii\rest\UrlRule', 'controller' => ['v1/goods'] ], ]
6、模擬請求操作
經(jīng)過上面幾個(gè)步驟,到此我們已經(jīng)為goods成功創(chuàng)建了滿足restful風(fēng)格的api了。為了更好更方便的演示,我們借助工具postman進(jìn)行模擬請求。
為了見證一下我們的操作,我們用postman請求一下GET /v1/goods看看結(jié)果如何:
從上面截圖中可以清楚的看到,GET /v1/goods 已經(jīng)能夠很方便的獲取我們表中的數(shù)據(jù)了。
當(dāng)然,yii2還對該api封裝了如下操作:
GET /users: 逐頁列出所有用戶
HEAD /users: 顯示用戶列表的概要信息
POST /users: 創(chuàng)建一個(gè)新用戶
GET /users/123: 返回用戶 123 的詳細(xì)信息
HEAD /users/123: 顯示用戶 123 的概述信息
PATCH /users/123 and PUT /users/123: 更新用戶123
DELETE /users/123: 刪除用戶123
OPTIONS /users: 顯示關(guān)于末端 /users 支持的動(dòng)詞
OPTIONS /users/123: 顯示有關(guān)末端 /users/123 支持的動(dòng)詞
不信的話我們可以利用postman發(fā)送一個(gè)post請求到/v1/goods,我們會(huì)發(fā)現(xiàn)成功創(chuàng)建了一個(gè)新的商品。
需要提醒的是,操作中還請細(xì)心且注意:
如果你的控制器末端不是復(fù)數(shù)(比如是blog非blogs)請保證請求的時(shí)候是復(fù)數(shù)!這是因?yàn)樵赗ESTful架構(gòu)中,網(wǎng)址中只能有名詞而不能包含動(dòng)詞,名詞又往往與數(shù)據(jù)表相對應(yīng),數(shù)據(jù)表呢又是一個(gè)“集合”,因此該名詞往往是復(fù)數(shù)的形式。
7、關(guān)于授權(quán)認(rèn)證
為什么需要授權(quán)認(rèn)證?這在一般的操作中是需要的。比如說用戶要設(shè)置自己的信息。
為了對yii2 restful授權(quán)認(rèn)證說的更清楚,我們將會(huì)以兩個(gè)兩種不同的方法進(jìn)行說明。
首先需要開啟認(rèn)證:
假設(shè)我們已經(jīng)按照第3步創(chuàng)建了包含字段access-token的數(shù)據(jù)表user,而且利用gii上生成了相應(yīng)的model和controller
配置main.php文件
'components' => [ 'user' => [ 'identityClass' => 'common\models\User', 'enableAutoLogin' => true, 'enableSession'=>false ], ],
為控制器配置authenticator行為指定認(rèn)證方式
<?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中實(shí)現(xiàn)findIdentityByAccessToken方法
public static function findIdentityByAccessToken($token, $type = null) { return static::findOne(['access_token' => $token, 'status' => self::STATUS_ACTIVE]); }
如此一來,我們先通過postman模擬不帶access-token請求看結(jié)果
{ "name": "Unauthorized", "message": "You are requesting with an invalid credential.", "code": 0, "status": 401, "type": "yii\\web\\UnauthorizedHttpException" }
提示401 我們沒有權(quán)限訪問!
我們在請求的鏈接上攜帶正確的access-token,認(rèn)證通過后,控制器會(huì)再繼續(xù)執(zhí)行其他檢查(頻率限制、操作權(quán)限等),才可以返回正確的用戶信息。
需要提醒的是:通過url的形式對access-token傳遞存在一定的風(fēng)險(xiǎn),有可能會(huì)造成數(shù)據(jù)的泄漏!一般而言,access-token需要放到HTTP頭中進(jìn)行傳遞!除非客戶端的請求是jsonp格式的!
8、速率限制
速率限制,該操作完全也是出于安全考慮,我們需要限制同一接口某時(shí)間段過多的請求。
速率限制默認(rèn)不啟用,用啟用速率限制,yii\web\User::identityClass 應(yīng)該實(shí)現(xiàn)yii\filters\RateLimitInterface,也就是說我們的common\models\User.php需要實(shí)現(xiàn)yii\filters\RateLimitInterface接口的三個(gè)方法,具體代碼可參考:
use yii\filters\RateLimitInterface; use yii\web\IdentityInterface; class User extends ActiveRecord implements IdentityInterface, RateLimitInterface { // other code ...... // 返回某一時(shí)間允許請求的最大數(shù)量,比如設(shè)置10秒內(nèi)最多5次請求(小數(shù)量方便我們模擬測試) public function getRateLimit($request, $action){ return [5, 10]; } // 回剩余的允許的請求和相應(yīng)的UNIX時(shí)間戳數(shù) 當(dāng)最后一次速率限制檢查時(shí) public function loadAllowance($request, $action){ return [$this->allowance, $this->allowance_updated_at]; } // 保存允許剩余的請求數(shù)和當(dāng)前的UNIX時(shí)間戳 public function saveAllowance($request, $action, $allowance, $timestamp){ $this->allowance = $allowance; $this->allowance_updated_at = $timestamp; $this->save(); } }
需要注意的是,你仍然需要在數(shù)據(jù)表User中新增加兩個(gè)字段
allowance:剩余的允許的請求數(shù)量
allowance_updated_at:相應(yīng)的UNIX時(shí)間戳數(shù)
在我們啟用了速率限制后,Yii 會(huì)自動(dòng)使用 yii\filters\RateLimiter 為 yii\rest\Controller 配置一個(gè)行為過濾器來執(zhí)行速率限制檢查。
現(xiàn)在我們通過postman請求v1/users再看看結(jié)果,會(huì)發(fā)現(xiàn)在10秒內(nèi)調(diào)用超過5次API接口,我們會(huì)得到狀態(tài)為429太多請求的異常信息。
{ "name": "Too Many Requests", "message": "Rate limit exceeded.", "code": 0, "status": 429, "type": "yii\\web\\TooManyRequestsHttpException" }
9、關(guān)于版本
為了兼容歷史版本而且考慮向后兼容性,我們在一開始操作的時(shí)候就以URL的方式實(shí)現(xiàn)了版本話,這里就不再進(jìn)行闡述了。
10、錯(cuò)誤處理
Yii的REST框架的HTTP狀態(tài)代碼可參考如下就好,沒啥好說的
200: OK。一切正常。
201: 響應(yīng) POST 請求時(shí)成功創(chuàng)建一個(gè)資源。Location header 包含的URL指向新創(chuàng)建的資源。
204: 該請求被成功處理,響應(yīng)不包含正文內(nèi)容 (類似 DELETE 請求)。
304: 資源沒有被修改??梢允褂镁彺娴陌姹尽?br />
400: 錯(cuò)誤的請求。可能通過用戶方面的多種原因引起的,例如在請求體內(nèi)有無效的JSON 數(shù)據(jù),無效的操作參數(shù),等等。
401: 驗(yàn)證失敗。
403: 已經(jīng)經(jīng)過身份驗(yàn)證的用戶不允許訪問指定的 API 末端。
404: 所請求的資源不存在。
405: 不被允許的方法。 請檢查 Allow header 允許的HTTP方法。
415: 不支持的媒體類型。 所請求的內(nèi)容類型或版本號是無效的。
422: 數(shù)據(jù)驗(yàn)證失敗 (例如,響應(yīng)一個(gè) POST 請求)。 請檢查響應(yīng)體內(nèi)詳細(xì)的錯(cuò)誤消息。
429: 請求過多。 由于限速請求被拒絕。
500: 內(nèi)部服務(wù)器錯(cuò)誤。 這可能是由于內(nèi)部程序錯(cuò)誤引起的。
相關(guān)文章
Laravel 在views中加載公共頁面的實(shí)現(xiàn)代碼
今天小編就為大家分享一篇Laravel 在views中加載公共頁面的實(shí)現(xiàn)代碼,具有很好的參考價(jià)值,希望對大家有所幫助。一起跟隨小編過來看看吧2019-10-10php實(shí)現(xiàn)微信公眾號企業(yè)轉(zhuǎn)賬功能
這篇文章主要為大家詳細(xì)介紹了php實(shí)現(xiàn)微信公眾號企業(yè)轉(zhuǎn)賬功能,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-10-10解決laravel(5.5)訪問public報(bào)錯(cuò)的問題
今天小編就為大家分享一篇解決laravel(5.5)訪問public報(bào)錯(cuò)的問題,具有很好的參考價(jià)值,希望對大家有所幫助。一起跟隨小編過來看看吧2019-10-10對于ThinkPHP框架早期版本的一個(gè)SQL注入漏洞詳細(xì)分析
這篇文章主要介紹了對于ThinkPHP框架早期版本的一個(gè)SQL注入漏洞詳細(xì)分析,對于網(wǎng)站安全十分重要!需要的朋友可以參考下2014-07-07