Download as PDF, PPTX
![24 で実装すると･･･ • ShopのCRUD • /shops [POST/GET] • /shops/{id} [GET/PUT/PATCH/DELETE] • 「Shopが販売するItem」のCRUD? • /items [POST/GET] • /items/{id} [GET/PUT/PATCH/DELETE] • 「ItemごとのPrice」のCRUD? • /prices [POST/GET] • /prices/{id} [GET/PUT/PATCH/DELETE]](https://image.slidesharecdn.com/springfest2017isaopublish-171124080528/75/Spring-Data-REST-API-24-2048.jpg)
![26 こんな感じを期待していた • ShopのCRUD • /shops [POST/GET] • /shops/{id} [GET/PUT/PATCH/DELETE] • 「Shopが販売するItem」のCRUD • /shops/{id}/items [POST/GET] • /shops/{id}/items/{id} [GET/PUT/PATCH/DELETE] • 「ItemごとのPrice」のCRUD • /shops/{id}/items/{id}/prices [POST/GET] • /shops/{id}/items/{id}/prices/{id} [GET/PUT/PATCH/DELETE] URLから 階層構造が 読み取れる](https://image.slidesharecdn.com/springfest2017isaopublish-171124080528/75/Spring-Data-REST-API-26-2048.jpg)
![34 リソース横断の をしたい • カスタムエンドポイントを作る • e.g. /items/{id}/prices [PATCH] • Spring Data RESTと通常の@Controller(@RestController)はConflictしないので、 エンドポイントの追加は問題ない • でもこれ、Spring Data RESTのリソース概念と対立する･･･ -> 1つのAPIの中でI/F設計がブレる](https://image.slidesharecdn.com/springfest2017isaopublish-171124080528/75/Spring-Data-REST-API-34-2048.jpg)
Uploaded byRakuten Group, Inc.
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
Spring Fest 2017での同名セッションの発表資料です。 http://springfest2017.springframework.jp/#session
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
- 1.
- 2. 2 1. Spring DataRESTの紹介 2. 実際のプロジェクトに適用してみよう 1. Spring Data RESTを使ってみる 2. Spring Data RESTを使ってみた結果 3. Spring Data RESTは使えるのか? 4. まとめ
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10. 10 の特徴 • と を定義したらが生える • 自前でロジックを書く必要が皆無 • 全部生える • 「特定の を公開しない」という設定もできるので安全 • の処理をよしなにやってくれる • 統一された フォーマット で やってくれる • ページングとかも超簡単
- 11.
- 12.
- 13.
- 14. 14 今回のお題アーキテクチャ • いっぱい 作る •データ層側は基本的にはシンプルな のみ • 中間層 ビジネスロジック から 複数のデータ層 データアクセス にアクセスする • データアクセス 同士は が揃っていてくれるととてもうれしい • 規約 • のフォーマット •
- 15. 15 の特徴 再掲 • とを定義したら が生える • 自前でロジックを書く必要が皆無 • 全部生える • 「特定の を公開しない」という設定もできるので安全 • の処理をよしなにやってくれる • 統一された フォーマット で やってくれる • ページングとかも超簡単
- 16.
- 17.
- 18.
- 19.
- 20. 20 お題データ構造 • お店(Shop)データ • 店名、フロア数を持つ •複数の商品を販売できる • 商品(Item)データ • 名前を持つ • 複数の料金設定を持つ • 料金設定(Price)データ • 「商品を何個買うといくらになるか」の 料金データを持つ • いわゆる『まとめ買い』価格を表現できる = ¥190 = ¥100 = ¥150
- 21.
- 22. 22 のクラスにすると、こう public class Shop{ private String name; private int floor; private List<Item> items; } public class Item { private String name; private List<Price> prices; } public class Price { private int unit; private BigDecimal amount; } 2個で¥190 駄菓子屋 1階建て チョコ 飴 1個 ¥150 2個 ¥190 1個 ¥100
- 23. 23 やりたいこと • ShopのCRUD • 「Shopが販売するItem」のCRUD •「ItemごとのPrice」のCRUD
- 24. 24 で実装すると･･･ • ShopのCRUD • /shops[POST/GET] • /shops/{id} [GET/PUT/PATCH/DELETE] • 「Shopが販売するItem」のCRUD? • /items [POST/GET] • /items/{id} [GET/PUT/PATCH/DELETE] • 「ItemごとのPrice」のCRUD? • /prices [POST/GET] • /prices/{id} [GET/PUT/PATCH/DELETE]
- 25.
- 26. 26 こんな感じを期待していた • ShopのCRUD • /shops[POST/GET] • /shops/{id} [GET/PUT/PATCH/DELETE] • 「Shopが販売するItem」のCRUD • /shops/{id}/items [POST/GET] • /shops/{id}/items/{id} [GET/PUT/PATCH/DELETE] • 「ItemごとのPrice」のCRUD • /shops/{id}/items/{id}/prices [POST/GET] • /shops/{id}/items/{id}/prices/{id} [GET/PUT/PATCH/DELETE] URLから 階層構造が 読み取れる
- 27. 27 で 生えてくる たち •全部がトップレベルリソース • リソース同士はrelationのリソース(/A/{id}/B/{id})で繋がる • そこには上位下位の関係性はない • ちょっとそれは「頭の中の階層構造」と違う･･･ Shop Item Price Shop Item Price Data REST上の構造 頭の中の構造
- 28.
- 29.
- 30. 30 やりたいこと • ShopのCRUD • 「Shopが販売するItem」のCRUD •「ItemごとのPrice」のCRUD • 「あるItem内のPrice全部」をまとめて更新したい
- 31. 31 リソース横断の をしたい • 「あるItem内のPrice全部」=複数のリソースをいっぺんに更新したい 商品 個数 価格 チョコレート 1 150 飴 1 100 飴 2 190
- 32. 32 リソース横断の をしたい • 「あるItem内のPrice全部」=複数のリソースをいっぺんに更新したい • 生えてくるエンドポイントは1つずつしか操作できない 商品 個数 価格 チョコレート 1 150 飴 1 100 飴 2 190
- 33. 33 リソース横断の をしたい • 「あるItem内のPrice全部」=複数のリソースをいっぺんに更新したい • 生えてくるエンドポイントは1つずつしか操作できない • 「1つずつAPI callすればいいじゃん」 -> トランザクション管理の問題が発生 商品 個数 価格 チョコレート 1 150 飴 1 100 飴 2 190
- 34. 34 リソース横断の をしたい • カスタムエンドポイントを作る •e.g. /items/{id}/prices [PATCH] • Spring Data RESTと通常の@Controller(@RestController)はConflictしないので、 エンドポイントの追加は問題ない • でもこれ、Spring Data RESTのリソース概念と対立する･･･ -> 1つのAPIの中でI/F設計がブレる
- 35.
- 36. 36 ビジネスロジックのモデル のモデル • SpringData RESTで生えてくるエンドポイントのI/Fは 良くも悪くもDBのデータ構造そのまま • DBのスキーマ変更＝APIのI/F変更 • 「パフォーマンスのためにDB設計変えたい」ってなったとき、 玉突きでビジネスロジックAPIも一緒に変更する必要がある データ アクセス API DB ビジネス ロジック API ここを変えたら こっちも 変えなきゃ
- 37. 37 ビジネスロジックのモデル のモデル • 案1.ビジネスロジックAPI側が頑張る • ビジネスロジックAPI側がDB設計の変更に追従する • 案2. データアクセスAPI(DB設計)側が譲歩する • DBのデータ構造を可能な限りビジネスロジック側に合わせる • パフォーマンスとか冗長性の排除とかは、諦める データ アクセス API DB ビジネス ロジック API
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46. 46 との別れ • 得たもの • 自由 •失ったもの • 時間 • 「Spring Data RESTがこうなってるから、○○はできない」 という言い訳
- 47. 47 が我々にもたらしていたもの • (良くも悪くも)制約 • 良いところ •実装すべきコードがとても少ない • 制約により選択肢が狭まる → 迷わない • イマイチだったところ • 制約が強い → その周辺の設計(DB、ビジネスロジックAPI)に強く影響してしまう
- 48.
- 49. 49 は使えないコなの • やりたいこととSpring DataREST Wayが合致すれば強い • 実際に使ってみたことで、合うもの/合わないものがはっきりと分かった • ちなみに、楽天トラベルの別プロジェクトでは絶賛本番稼働中 • 無理やり使おうとするのがダメだった • あえて制約を強くしているものに対して、抜け道を探しまくるのは良い手ではない
- 50. 50 まとめ • Spring DataRESTで簡単にRESTful APIを作れる • 用法用量を守って使いましょう • Spring Data RESTが輝ける場所で採用しましょう • たくさんの階層構造を持たないデータ • 「リソースごとの単純なCRUDしかしない」ようなデータ
- 51. 51 引用文献 GitHub •https://github.com/logos Qiita •http://help.qiita.com/ja/articles/others-brand-guideline いらすとや •http://www.irasutoya.com/p/terms.html フリー素材 ピクトグラム •https://free-pictograms.com/ Spring DataREST •https://projects.spring.io/spring-data-rest/ •Accessed on 2017-11-21