やったこと

• APIデザインパターン 14章 アソシエーションリソース 読了

学んだこと

ポイント

• アソシエーションリソースとは
• アソシエーションリソースの利点
• アソシエーションリソースが持つべき特性
  • 標準メソッドの動作
  • 一意性
  • 更新

学び

• アソシエーションリソースは、リソース間の関係情報を保持するリソース
• アソシエーションリソースを提供するメリット
  • メタデータを持たせることが出来る
  • エイリアスを定義することで、より直感的なI/Fを提供できる
• アソシエーションリソースは、以下の点が、他のリソースとは扱いが異なる
  • 標準メソッドの動作
  • 一意性
  • 更新処理

メモ

対象とする問題

多対多のリソースをAPIで扱いたい。
RDBでは「結合テーブル」を使用して管理するが、これをAPIで公開する方法を検討する。
そして、「結合テーブル」の行を、二つのリソース間の関連を表す個別のリソースとして公開する具体的な方法を提供する。

概要

「結合テーブル」を、アソシエーションリソースとして、APIで提供する。
アソシエーションリソースもリソースの一種なので、標準メソッドで扱うことが出来る。

• フィルターも定義可能

加えて、アソシエーションリソースに、リソース間関係に関するメタデータを持たせることが出来る。

• 持たせる情報の例) いつ関連付けられたか、役割は何か、など

アソシエーションエイリアスメソッド

アソシエーションリソースを使用したフィルタリングのうち、よく使用されるフィルタリングに別名（エイリアス）を付けてアクセスしやすくする戦略。

良く使用されるフィルタリングは、カスタムメソッドとして定義してしまう。

実装

名付け

結構難しい。
悩む場合は、 "Membership"や"Association"といった単語を用いると良い。
汎用的な名前（"Membership"だけ、など）を付ける場合は、コンテキストによって意味が識別できなければならない。

標準メソッドの動作

create , list, deleteは、リソース間の関連付け情報を操作するため必須。
get,updateは、メタデータを使用する場合は実装する。
つまり、getおよびupdateは、メタデータに対してのみ実施する。

アソシエーションリソースの一意性

あるリソース間のアソシエーションリソースは、常に一組でなければならない。
言い換えると、全く同じアソシエーションリソースを複数作成することが出来ない。
そのために、アソシエーションリソース作成時に検証を挟む必要がある。

• 作成を試みた場合、 409 conflictなどでエラー扱いする事

アソシエーションリソースの更新

リソース間の関連を更新する場合、 updateでは実施しない。
古いアソシエーションリソースを削除後、新しいアソシエーションリソースを作成する形で更新する。

updateで更新できるのは、アソシエーションリソースのメタデータのみ。

参照整合性

アソシエーションリソース一方を削除する場合、以下の動作が考えられる。

オプション	動作
カスケード	削除されたリソースを指すアソシエーションリソースを、全て削除する
制限	他のリソースが参照しているリソースを、削除しないようにする
nullを設定	削除されるリソースへのポインタをすべてnullにする
何もしない	リソースを削除しても、ポインターは何もせず、無効なままにしておく

どれを選択するかは、アプリケーションの要件次第。
良く設定されるのは、「制限」と「何もしない」の二つ。

トレードオフ

複雑さ

アソシエーションリソースは非常に柔軟性が高い。
一歩間違えると、I/Fは複雑化し、直感的ではなくなる。
加えて、アソシエーションリソースの分だけ、考慮するリソースが増える。
開発側は保守対象が増え、利用者側は学習コストが増加する。

アソシエーションによる分離

対象としているデータは同じなのに、リソースとしては「アソシエーションリソース」と「アソシエーションリソースにリンクするリソース」の二つに分離されてしまう。

---

扱うこと

• アソシエーションリソースで多対多の関係を扱う方法
• アソシエーションリソースに付ける名前
• アソシエーションリソース用の標準メソッドのサポート方法
• 参照整合性をどのように扱うか

まとめ

• APIでは、「アソシエーションリソース」を使用することで、リソース間の多対多関係をモデル化できる
  • 二つのリソース間の関係を表現する最も柔軟な方法
  • 二つのリソース間の関係に関するメタデータも保持できる

---

ChatGPT

それぞれの方針には、利点と欠点があります。以下にそれぞれの利点と欠点をまとめてみましょう。

1. 古いデータを削除した後、新しいデータを作成する（DELETE + INSERT）

利点:

• シンプルな手法であり、データの削除と新規作成のステップが明確で理解しやすい。
• データの整合性が保たれやすく、更新処理による問題が起こりにくい。
• 新しいデータが元のデータと全く異なる構造を持つ場合でも対応できる。

欠点:

• データの削除と挿入の操作が二つに分かれているため、トランザクション管理が複雑になることがある。
• 大量のデータを扱う場合、削除と挿入のオペレーションに時間がかかる可能性がある。
• データの削除後にエラーが発生した場合、元のデータは失われる可能性がある。

1. 既存のデータに対して更新処理を実施する（UPDATE）

利点:

• 一度の操作でデータを更新できるため、トランザクション管理が容易になる。
• 更新のみが行われるため、DELETE + INSERTよりも効率的である場合がある。
• データの削除が発生しないため、データの損失が防げる。

欠点:

• 更新処理が複雑になることがあり、特に複雑なデータ構造の場合や複数のテーブルにまたがる更新の場合には工夫が必要になる。
• 更新操作によってデータの整合性が崩れる可能性がある。特に、複数のユーザーが同時に更新を行う場合には注意が必要。
• 一部のデータのみを更新する場合でも、データベースの全体をスキャンする必要がある場合があるため、パフォーマンスが低下する可能性がある。

どちらの方針が適しているかは、具体的なデータの特性やアプリケーションの要件によって異なります。データベースの機能や制約、トランザクション管理、パフォーマンス、データの整合性などを考慮して、適切な方法を選択する必要があります。