當設計一個RESTful API時，應該依賴於其他資源的資源被建模爲子級uis還是應該彼此簡單地引用？建模與RESTful API的資源關係
E.g.假設一個門總是依賴一個房子，那麼
/house/73/door/1
或
/house/73
/door/1044
這裏的房子，門包括相互之間的引用？
我發現的大多數RESTful API都非常平坦，所以我會重視任何具有更復雜關係依賴關係的引用。
Regards
在UML術語中，如果關係是Aggregation的關係，那麼你使用一個扁平的層次結構和事物之間的鏈接，而如果關係是Composition的關係（即一個door的生命週期嚴格受到一個house）你使用子資源。
我不是在建議繪製一個UML圖！但它確實有助於銘記這種區別。 （您也可以通過將子資源重定向到真實的子資源來對聚合案例進行建模;重定向爲 RESTful.OTOH，我實際上並不喜歡這樣做;我傾向於明確任何關係並保持重定向向下的數目。）
請記住，URI是服務器的實現細節。如果你可以將它們建模爲平坦資源，那麼就這樣做。服務器處理它們會更容易。
如果門的標識符在所有房屋中都不是唯一的，那麼您的服務器將需要知道房屋，因此您需要將房屋包含在URI中。
資源之間的關係應該通過返回表示中的鏈接建模。即您的房屋代表應該包含指向該房屋所有門戶資源的鏈接。我建議儘量避免使用URL結構具有某些域的含義。
只有在需要唯一標識資源時才使用層次結構。
我還會提到例如酷的URIs不會改變。換句話說，不要將東西添加到不是永久的URI中。因此，如果'73'是數據庫中的主鍵，那麼您將無法輕鬆地合併數據庫... – mogsie 2010-09-24 18:02:30