Backbone.js的與REST API資源的關係及interraction

我有一個正在由提供Backbone.js的單個頁面的Web應用程序所消耗的小REST APIBackbone.js的與REST API資源的關係及interraction

有API提供了兩種資源類型，因此，，骨幹應用程序使用。這些是文章和評論。這兩個資源具有不同的端點，並且每個文章都有一個鏈接到該文章所有評論的位置。

我面對的問題是，在我的web應用程序的文章列表中，我希望能夠顯示每篇文章的評論數量。鑑於這隻有在我也可以獲得評論列表的情況下才能實現，在當前的設置下，將需要我提出一個API請求以獲得最初的文章列表，並且每個文章的另一個請求能夠計數的評論。例如，如果有100篇文章，那麼這將成爲一個問題，因此需要101個HTTP請求來填充單個視圖。

我能想到的，現在的解決方案是：

1至包括在最初文章的評論數據請求，像這樣

{ 
    { 
    "id": 1, 
    "name": "Article 1", 
    ... 
    "comments": { 
     { 
     "id": 1, 
     "text": "some comment" 
     }, 
     { 
     "id": 2, 
     "text": "some comment" 
     }, 
     ... 
    } 
    }, 
}

在這種情況下的問題是：如何有可能將「評論」解析爲單獨的評論集合，而不是將其納入文章模型中？

2.包括一些元數據文章內響應，像這樣：

{ 
    { 
    "id": 1, 
    "name": "Article 1", 
    ... 
    "comments": 13 
    }, 
}

選項是提出了一個問題：我應該如何處理模型的解析，這樣，一方面元信息是可用的，另一方面，「評論」屬性不是一個骨幹會嘗試執行更新？

我覺得有可能是另一種解決方案，符合REST理念，因此我錯過了，所以如果您有任何其他建議，請讓我知道。

來源

2012-09-27 titel

我認爲你最好的選擇是和你的第二個選擇一起去，在你的文章模型中包含每篇文章的評論數量。

選項是提出了一個問題：我應該如何處理模型的解析，這樣，一方面元信息是可用的，而在另一方面，「意見」屬性不是一個骨幹會嘗試執行更新？

不確定你的問題在這裏。爲什麼你會擔心評論屬性得到更新？

我想不出任何其他的「RESTy」方式來達到你想要的效果。

來源

2012-09-27 13:03:42 Harborhoffer

我會建議使用替代2和讓服務器返回一個子與文章收集資源（或許在/articles可達）打交道時被認爲有用的應用文章屬性。

其所有評論（無論它們存儲在後臺單獨的表）完整的文章成員資源將提供/articles/:id）。

從一個Backbone.js的點，你可能想要把收集資源的，比方說，ArticleCollection將轉換每個成員（目前與屬性的子集）到Article模型。

當用戶選擇全額查看文章你拉出來從ArticleCollection並調用fetch填充它完全。

關於如何處理在集合資源（/articles）之類的評論數和其他可能的usefult聚合包括額外的/虛擬的屬性做，我看到幾個備選方案：

在Article#initialize你可以將它們從attributes 中拉出來，並將它們作爲元數據存儲在文章中。這樣內置的 Backbone.Model#toJSON將不會看到它們。
將它們保留在每個型號的attributes部分中，並覆蓋 Backbone.Model#toJSON以在「序列化」Article時使用它們。

在atlernative 1，Article#commentCount()幫手可以返回 this._commentCount || this.get('comments').length，使其工作在兩個部分和滿載物品。

對於滿載Article你可能會想在嵌套comments數組轉換成一個完全成熟的CommentCollection反正並存儲在this._comments，所以我不認爲這是不尋常有你的模型存儲的其他在attributes散列之外的模型實例上直接填充。

來源

2012-09-27 13:06:24 Greg

Backbone.js的與REST API資源的關係及interraction

回答

相關問題