やったこと

APIデザインパターン 4章リソースの範囲と階層読了

学んだこと

ポイント

階層関係を構築すべき場合/すべきでない場合

学び

不必要な参照は持たない

気づき

メモ

リソースレイアウトとは何か

APIの特定の設計における実体（リソース）関係モデルを表す。

リソースの配置
リソースのフィールド定義
リソース間の関連

リソースレイアウト設計は、DB設計と似通ったモノがある。
書籍では、UMLのクラス図でリソース間の関係を表現している。

関係にも、いくつかの種類がある。

◇参照関係
あるリソースが、別のリソースを指している状態。
Userリソースと、Messageリソースなど

◇多対多の関係
リソースが、複数の他のリソースを指している状態。
Userリソースと、CharRoomリソースなど

◇自己参照関係
ある型Aのインスタンスが、同じ型の、異なるインスタンスを参照している状態。
グラフ構造やリスト構造など

◇階層関係
包含関係や所有関係を保持しつつ、あるリソースが別のリソースを指している状態。
木構造など。
親要素に対して実行できる操作を、子要素にも実行できることが期待される。
これは、利点にもなるし、欠点にもなる。

正しい関係を選ぶ

不必要な参照は持たない

リソース決定後、リソースの関係を決定することになる。
この時、不必要な参照は持たないよう心掛ける。

不必要な参照は、データ量増加に伴い、運用保守が困難になる、パフォーマンスの低下などを引き起こす

インラインと参照

データの保持にはインライン保持と参照保持があり、それぞれ特徴がある。

保持方法	特徴	利点	欠点
インライン	複製したオブジェクトを保持する	リソース取得時、一々APIを叩く必要がない	データサイズが重くなる
参照	オブジェクトのポインタのみ保持する(idだけ持つなど)	データサイズが軽くなる	オブジェクトが必要な場合、リソース取得処理が必要になる

ユースケースに応じて、インラインと参照どちらを使用するべきかが変化する。

常にデータを参照したい場合、リソース取得処理が少なくなるインラインに軍配が上がる
あまり参照しない場合は、処理高速化のため参照に軍配が上がる

階層関係

例えば、親リソースを削除すると、子リソースも削除されることが期待される。
このように、処理や認可が連鎖するような関係は、利点にも欠点にもなる。

以下のどちらにも当てはまる場合、階層関係は有益。

「親リソースを削除した場合、子リソースも削除されるべき」という場合
「親リソースへアクセス可能となった場合、子リソースにもアクセスできる」という場合

以下に当てはまる場合、階層関係はNG。

子リソースの親が、常に一つの場合
- 言い換えると、既に親を持つ子リソースは、他の親を持つことが出来ない場合

アンチパターン

あらゆるデータをリソース化する

リソースとして扱うか、データ型（一プロパティ）として扱かは、

データＡが、リソースＢからしかアクセスされない場合、データＡはデータ型で問題ない
- つまり、リソース化しない方が良い
- 複雑になるだけ
データＡについて、直接操作したく、かつインライン化可能であれば、インラインで問題ない
- つまり、リソース化しない方が良い

深い階層

過度に深い階層は、理解するのが困難で、管理が難しくなる。
ユースケースに応じて、同レベルに配置する、一つのデータにまとめるなどして、不必要に深くしないようにしよう。

全てのデータをインライン化する

「全てインライン化する」とは、つまり一つのリソースにまとめること。

リソースの一部にだけアクセスしたい場合でも、不要な部分も含めてデータも呼び出すことになり、パフォーマンスが低下する。

あるデータＡが、複数のリソースから参照される場合、データＡはリソース化しよう。
- つまり、インライン化しない

扱うこと

リソースレイアウトとは何か
様々な種類のリソース関係（参照、多対多など）
実体関係図によるリソースレイアウトの記述
リソース間の適切な関係を決める方法
避けるべきリソースレイアウトのアンチパターン

まとめ

リソースレイアウトとは、API内のリソースの配置と関係を指す
APIに重要な機能を提供する場合にだけ関係を持たせるようにする
- API内のすべてのリソースをつなぎたくなる誘惑に打ち克つ
ある概念について、「個別のリソース」とした方が良い場合と、そのデータをインライン化し、概念をデータ型として残した方が良い場合がある
- これは、概念とそのやりとりにアトミック性が必要かどうかで判断する
過度に深い階層的な関係は理解が困難で管理が難しくなるため避ける

t0mmy

学習履歴詳細

API デザインパターン 4章読了