Advertisement
CakePHP3で学ぶAPIマネジメント #phpconfuk
May. 21, 2016•0 likes•4,876 views
5 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Technology
PHPカンファレンス福岡2016での登壇資料です！
Yuta MatsumuraFollow
Advertisement
CakePHP3で学ぶAPIマネジメント #phpconfuk
- 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 バージョンが一つあがった だけっしょｗｗｗ
- 26 バージョンが一つあがった だけっしょｗｗｗ 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
- ありがとうございました。
Editor's Notes
- 弊社はMicrosoft AzureやAWSをプラットフォームとした業務システムの開発や運用を主に行っております。 弊社のことを少しでも知っている方は、弊社はAzureのイメージが強かったりすると思います。 しかし弊社は特に技術のこだわりはなく、お客様の要望を実現するための最良を選択しています。
- なので弊社は主にASP.NETとCakePHPの２つを使用して、Webアプリケーションの開発を行っています。 この２つのフレームワークに共通しているのはMVCという概念で構成されているということです。
- MVCとはModel,View,Controllerという３つの機能で構成されています。 昨年、MVCをフル活用してシステム開発を行っていましたが、苦しい思いをすることもありました。それはViewです。
- ひとまずMVCについておさらいします。（スライド説明）
- （スライドを先に説明） ASP.NETはVisual Studioというオールインワンの統合開発環境がありますが、それでもViewが絡む開発は大変です。
- 極端な例ではありますが、Viewが絡むとこのような事態が発生する可能性があります。 MVCは密結合な構成であるがゆえ、便利な部分もありますが不便な部分もあるように感じてきました。
- （スライドを一通り読む）
- そこで弊社はViewを使うのをやめました。代わりにフロント側はHTMLとJavascriptの静的ページにしました。つまり…
- （スライドを読み上げる） API化することでModelやControllerを含むバックエンドと、Viewを含むフロントエンドが疎結合となることを図りました。 APIが汎用的なデータを提供し、フロントエンドが好きなようにそのデータを使用する、という構図になります。 弊社がこれまでAPI構成で行ってきた開発の大半はCakePHPを利用しています。そこでこれまでの開発について紹介します。
- 昨年10月、本格的なAPI形式での開発が始まりました。このプロジェクトは私が担当し、社内でAPI開発の実験台となりました。 このプロジェクトではリリースされて日が浅かったCakePHP3を採用しました。 結果として出来上がったのは今思えばAPIぽいものでした。
- 今年1月からのプロジェクトでは私は設計の基礎づくりに携わりました。 詳しくは後ほど紹介しますが、この時に参考にしていた書籍はこちらの２つです。 特に左の書籍は弊社のAPI設計のバイブルとなり、付箋だらけになっています。
- そして3月から現在も続いているプロジェクトではこれまでの経験を踏まえて、REST構成を意識したAPI設計を行っています。
- これまでのプロジェクトを踏まえて、私がAPI設計を行う上で軸としているのがこちらです。 （スライドの説明） APIで大事なのは何と言ってもI/Oです。I/OとはAPIの入力と出力です。 弊社が開発するAPIは、入力と出力ともにJSONを使用しています。 I/Oに対する、設計者、開発者、利用者の認識違いを減らせば、APIとしての機能要件を満たすと考えています。
- （スライドを読む）この仕組みを踏まえた設計をすることでAPIがどんな役割なのか、イメージしやすくなります。この部分がデザインであると思っています。
- 各プロジェクトの前に、API設計書を見直し、フォーマットとしての精度をあげるように努めています。
- CakePHP2では一つだったModelが、CakePHP3ではEntityとTableという２つの構成になっていました。 はじめはEntityとTableがそれぞれどういった役割なのか、把握することが難しかったです。 しかもVer3.0時点で日本語情報も少なく、英語の公式ドキュメントを読み漁る日々でした。
- CakePHP2では一つだったModelが、CakePHP3ではEntityとTableという２つの構成になっていました。 はじめはEntityとTableがそれぞれどういった役割なのか、把握することが難しかったです。 しかもVer3.0時点で日本語情報も少なく、英語の公式ドキュメントを読み漁る日々でした。
- CakePHP3では意外と簡単にAPIを作ることができます。CakePHP3の構成自体がAPIとしての利用をにらんでいるという印象を受けました。（スライド説明）
- たったこれだけでAPIを作ることができます。基本構成は簡単ですね。あとは認証等、要件に応じた実装になると思います。
Advertisement