REST API數據庫結構

在構建一個簡單的REST Api時，我有「book」和「bookCategory」。
他們電學性能的研究是非常簡單的和相同的：REST API數據庫結構

book {id, name, created_at, modified_at } 
bookCategory {id, name, created_at, modified_at }

如果我只有這個表，我會離開它這樣，但我有「電影」相同的邏輯和結構，「畫」，「視頻遊戲「等。將它們拆分成不同的表格是一種很好的做法，即使它們具有相同的結構，但邏輯上它們是不同的。我能做到這一點，節省了我很多的表，控制器和形式（保持乾燥）：

things {id, **parent_id**, name, created_at, modified_at, **type** }

一些例子

1 | 0 | "Comedy" | "movie" 

2 | 1 | "Dumb and Dumber" | "movie" 

3 | 1 | "Ace Ventura" | "movie" 

4 | 0 | "Fantasy" | "book" 

5 | 4 | "Lord of the Rings" | "book"

這是非常緊湊的，但如何將看起來像「所有電影類別」或「所有類別」的終結點？或者更好地鋪設一個靈活的地面結構（也許會有新的屬性來）？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？

來源

2014-03-28 user1930254

由於您已經定義了問題空間，所以使用垂直表是合理的 - 假設您預計不會有一個新的屬性對於一個實體是唯一的（例如「作者」，可能在書上和電影，但不是bookCategory或movieCategory）。如果您預計新的獨特屬性（或不確定），我會建議每個表單獨。雖然你現在違反DRY，但後來改變的成本會很高。

至於終點，

GET /api/movieCategories 
<- an entity with all movie categories

再次，如果所有類別已經和將始終具有相同的屬性，這將是合理的，而不是做

GET /api/categories?type=movie

來源

2014-03-28 10:59:42

REST API數據庫結構

回答

相關問題