CakePHP3で学ぶ
APIマネジメント
2016/05/21 PHPカンファレンス福岡
松村 優大
自己紹介
• 松村 優大(MLBお兄さん)
• 島根出身の28歳
• 株式会社オルターブース
• テクニカルアーキテクト
2
会社紹介
福岡発
フルスタックサービス開発
つまらない世界からお客様を解放させ、
もっと刺激のある世界へ変化させよう!
3
よく使うWebフレームワーク
4
5
Controller
Model View
6
• データ(≒テーブル)の管理
• ビジネスロジック
Model
• ユーザインターフェースを表現
• Controllerからデータが渡る
View
• ModelからViewへ出力データを渡す
• ViewからModelへ入力データ渡す
Controller
Viewはツラいです・・・
• デバッグが難しい、または出来ない
• 実行時エラー(=例外)が発生して初めて
バグに気付く
• ControllerからViewへのデータ連携が
ネック
• CakePHP ... viewVars
• ASP.NET ... ViewBag, ViewData
7
8
コ「userName とい
う変数に氏名を設定
しといたからな!」
ビ「userName とい
う変数にある氏名を
表示するで!」
コ「氏名を設定する
変数を staffName に
変更したで!」
修正
ビ「userName って
変数が無くなっとる
やんけ!」⇒例外
密結合
9
10
11
実装済みの機能に修正を加える場合もあ
るし、製造時と修正時の担当者が異なる場
合も多々ある。
データの受渡し方にルールを設けるべき
だという考えも分かるが、そもそもこのよう
なデータの受渡し方を行うことにリスクがあ
るのではないか。
もっと品質を高められる仕組みはないか。
テツヤシタクナイ。
12
Controller
Model
HTML
JavaScript
13
Viewを使わず
データはAPIで提供
2015年10月~
APIぽいもの
API設計の基礎不足を痛感
ダサいエンドポイント
/api/getUserName とか…。
v3.0
14
2016年01月~
猛勉強ターン
15
v3.1
2016年03月~
RESTAPI & SPA
APIデザインを勉強し、規
模の大きな開発で実践中
16
v3.2
APIの品質を高める仕組み
1. 開発者/利用者にとって易しいAPI設計
2. フレームワーク機能の適切な利用
3. プルリクエストによるコードレビュー
4. エンドポイント単位の単体テスト
17
設計:リクエスト
• HTTPメソッド
• 認証方式
• パラメータ
• GET : クエリパラメータ
• POST/PUT : JSON
• 型、必須かどうかも明記
18
設計:レスポンス
• 正常系レスポンス項目
• GET : ページング情報も付加
• JSONレスポンスの例を明記
• 異常系レスポンス項目
• エラー情報とステータスコードを明記
• JSONレスポンスの例を明記
19
設計:詳細設計
• API内部での処理を記載
• リクエスト情報、レスポンス情報では
伝わりにくい部分を明記
20
設計:単体テスト
• API設計時にテストケースも考える
• リクエストパラメータのパターンテスト
• 取得件数やソートに関するパターンが
意外と漏れる
• 単体テストはPHPUnitを使用
• ステータスコードのチェック
• レスポンスJSONの想定と実際の比較
21
22
Input/Outputを明確にする
APIの挙動のイメージが容易
フロントエンドで
APIが利用しやすくなる
23
本編では弊社の
API設計書フォーマット
をお見せしました
CakePHP3を採用したワケ
• CakePHP2での開発経験 #NOT実務レベル
• こだわりはほとんど無い
• MVCフレームワークであること
• O/Rマッパー機能をもつこと
• せっかくだから最新のCakePHP3を採用
24
25
バージョンが一つあがった
だけっしょwww
26
バージョンが一つあがった
だけっしょwww
Entity Table
Model
Entity
• レコード
• 列=プロパティ
• バリデーション
Table
• DBテーブルを操作
• find(er)
• TableRegistry
27
http://book.cakephp.org/3.0/ja/orm.html
http://qiita.com/kozo/items/87dc9f725e71dd742468
http://qiita.com/morisuke/items/e466d2ab360ab5646e9a
CakePHP3でAPIを作る手順
1. ルーティングの設定
2. ビューの準備
3. CRUDメソッドの定義
http://book.cakephp.org/3.0/ja/development/rest.html
28
1. ルーティングのスコープ切り分け
※よくみる /api/ のあれ
2. 拡張子の指定( json, xml, etc )
3. RESTアクセスしたいリソースを指定
※リソース=Model
http://book.cakephp.org/3.0/ja/development/routing.html#restful
ルーティングの設定
29
ビューの準備
1. JSON形式のレスポンスには
CakeViewJsonView が使用される
2. JsonViewのマルチバイト対応
3. AppController->beforeRender にて
マルチバイト対応JsonViewを適用
http://blog.doizaki.com/entry/2015/05/19/050106
30
$ curl http://localhost/api/users.json
{
"users": [
{
"id": 1,
"name": "u3086u3046u305f"
}
]
}
31
CRUDメソッドの定義
1. スキャフォールドのCRUDメソッドでも
APIとして動作する
2. レスポンスデータを連想配列化
32
HTTPメソッド エンドポイント メソッド
GET /users Index()
GET /users/:id view($id)
POST /users add()
PUT /users/:id edit($id)
DELETE /users/:id delete($id)
課題
• 認証
• HTTPヘッダの適切利用
• RESTのネスト構成
• /company/:id/employee/:id みたいな
• CakePHPプラグイン
33
ありがとうございました。

CakePHP3で学ぶAPIマネジメント #phpconfuk

Editor's Notes

  • #4 弊社はMicrosoft AzureやAWSをプラットフォームとした業務システムの開発や運用を主に行っております。 弊社のことを少しでも知っている方は、弊社はAzureのイメージが強かったりすると思います。 しかし弊社は特に技術のこだわりはなく、お客様の要望を実現するための最良を選択しています。
  • #5 なので弊社は主にASP.NETとCakePHPの2つを使用して、Webアプリケーションの開発を行っています。 この2つのフレームワークに共通しているのはMVCという概念で構成されているということです。
  • #6 MVCとはModel,View,Controllerという3つの機能で構成されています。 昨年、MVCをフル活用してシステム開発を行っていましたが、苦しい思いをすることもありました。それはViewです。
  • #7 ひとまずMVCについておさらいします。(スライド説明)
  • #8 (スライドを先に説明) ASP.NETはVisual Studioというオールインワンの統合開発環境がありますが、それでもViewが絡む開発は大変です。
  • #9 極端な例ではありますが、Viewが絡むとこのような事態が発生する可能性があります。 MVCは密結合な構成であるがゆえ、便利な部分もありますが不便な部分もあるように感じてきました。
  • #12 (スライドを一通り読む)
  • #13 そこで弊社はViewを使うのをやめました。代わりにフロント側はHTMLとJavascriptの静的ページにしました。つまり…
  • #14 (スライドを読み上げる) API化することでModelやControllerを含むバックエンドと、Viewを含むフロントエンドが疎結合となることを図りました。 APIが汎用的なデータを提供し、フロントエンドが好きなようにそのデータを使用する、という構図になります。 弊社がこれまでAPI構成で行ってきた開発の大半はCakePHPを利用しています。そこでこれまでの開発について紹介します。
  • #15 昨年10月、本格的なAPI形式での開発が始まりました。このプロジェクトは私が担当し、社内でAPI開発の実験台となりました。 このプロジェクトではリリースされて日が浅かったCakePHP3を採用しました。 結果として出来上がったのは今思えばAPIぽいものでした。
  • #16 今年1月からのプロジェクトでは私は設計の基礎づくりに携わりました。 詳しくは後ほど紹介しますが、この時に参考にしていた書籍はこちらの2つです。 特に左の書籍は弊社のAPI設計のバイブルとなり、付箋だらけになっています。
  • #17 そして3月から現在も続いているプロジェクトではこれまでの経験を踏まえて、REST構成を意識したAPI設計を行っています。
  • #18 これまでのプロジェクトを踏まえて、私がAPI設計を行う上で軸としているのがこちらです。 (スライドの説明) APIで大事なのは何と言ってもI/Oです。I/OとはAPIの入力と出力です。 弊社が開発するAPIは、入力と出力ともにJSONを使用しています。 I/Oに対する、設計者、開発者、利用者の認識違いを減らせば、APIとしての機能要件を満たすと考えています。
  • #23 (スライドを読む)この仕組みを踏まえた設計をすることでAPIがどんな役割なのか、イメージしやすくなります。この部分がデザインであると思っています。
  • #24 各プロジェクトの前に、API設計書を見直し、フォーマットとしての精度をあげるように努めています。
  • #26 CakePHP2では一つだったModelが、CakePHP3ではEntityとTableという2つの構成になっていました。 はじめはEntityとTableがそれぞれどういった役割なのか、把握することが難しかったです。 しかもVer3.0時点で日本語情報も少なく、英語の公式ドキュメントを読み漁る日々でした。
  • #27 CakePHP2では一つだったModelが、CakePHP3ではEntityとTableという2つの構成になっていました。 はじめはEntityとTableがそれぞれどういった役割なのか、把握することが難しかったです。 しかもVer3.0時点で日本語情報も少なく、英語の公式ドキュメントを読み漁る日々でした。
  • #29 CakePHP3では意外と簡単にAPIを作ることができます。CakePHP3の構成自体がAPIとしての利用をにらんでいるという印象を受けました。(スライド説明)
  • #33 たったこれだけでAPIを作ることができます。基本構成は簡単ですね。あとは認証等、要件に応じた実装になると思います。