アイテムが階層ツリー構造に分類される従来のデータ モデルがあります。
example.com/myanimals/pet/dog/{mydog_ID}
example.com/myanimals/pet/cat/{mycat_ID}
example.com/myanimals/birds/{mybirds_ID}
上記のような URL でアドレス可能な RESTful API を公開したいと考えています。
- URLの最後の要素がアイテムの場合、アイテムと、場合によってはアイテムカテゴリのサブカテゴリを表示する必要があります
- 最後の要素がカテゴリの場合、その項目とそのサブカテゴリのリストを表示する必要があります。
次に、カテゴリまたはアイテムに対処している場合、2 つの異なる動作が発生します。私は Java で RESTLet ライブラリを使用していますが、私の質問は次のとおりです。
- (理論上の) カテゴリの無限パスによってリソースに対処するのは RESTful なアプローチですか?
- そのようなデータ モデルの URL を RESTful な方法でモデル化する最良の方法は何ですか?
もう1つの問題は、その設計では、 animal の後のすべての文字を解析し、最後の要素がカテゴリ自体であるかアイテムであるかをテストし、最後に適切な表現でリソースを処理する必要があることです。これは、カテゴリとアイテムの名前空間が 1 つであることも意味し、カテゴリとアイテムに一意の名前を付ける必要があります。
アップデート
わかりました最終的に私はこのデザインになりました：
/animals -> read all animals
GET /animals/categories/cat1/cat2 -> read all animals (as a list) and/or subcategories of cat2 (parameterized with query param)
/animals/name -> handle specific animal
/animals/categories -> read root categories
PUT/DELETE/POST /animals/categories/cat1/cat2 -> handle all subcategories of cat2
/animals/tags/tag -> read list of all animals labeled with this tag
- 最初の設計では、名前空間のカテゴリと動物が競合していました: 作成要素のルーティングに重大な問題がありました: POST /informationmodels は動物の作成またはカテゴリの作成にルーティングされるべきでしたか?
- ファイル システムのような URL デザイン /animals/cat1/cat2/.../animalname では、動物のアイテムまたはカテゴリを取得してからアイテムのリストを取得する場合、クライアントはそうしません。
上記のソリューションはこれらの問題を正しく処理しているように見えますが、これらは予約済みのキーワードであるため、名前のカテゴリまたはタグを持つ動物はアドレス指定できないことだけを知っておく必要があります。