Javascript 在单页应用程序中使用视图模型、合并响应还是遵守REST标准？

例如，当您使用ASP.NET MVC创建单页应用程序，使用REST创建一些Web API控制器时，往往会向服务器发出大量请求，因为视图通常依赖于一些复杂的数据。在一个普通的网络项目中，我肯定会尽可能少地创建请求，也许这适用于单页应用程序？在我的例子中，我的应用程序依赖于两种类型的对象和一些相同类型的集合。在客户端，我使用Backbone.js，我的控制器为

Get（）

分别处理一种类型，应该实现与REST类似的

Get（int-id）

。在我的例子中，这不是一个开放API，只是我的应用程序使用它。这是我的应用程序所依赖的JSON的一个示例

{
    CurrentPage: {
        Heading: "Home",
        Id: "pages/193",
        Metadata: {
            Name: "Home",
            Title: null,
            Keywords: null,
            Description: null,
            DisplayInMenu: true,
            Published: "/Date(1334499539404)/",
            Changed: "/Date(1334499539404)/",
            ChangedBy: "Marcus",
            IsPublished: true,
            IsDeleted: false,
            Slug: null,
            Url: null,
            SortOrder: 0
        },
        Parent: {
            id: "pages/293",
            slug: "slug",
            url: "url"
        },
        Children: [
            "pages/226",
            "pages/257"
        ]
},
    ParentPage: {
        Heading: "Parent",
        Id: "pages/293",
        Metadata: {
            Name: "Parent",
            Title: null,
            Keywords: null,
            Description: null,
            DisplayInMenu: true,
            Published: "/Date(1334499539404)/",
            Changed: "/Date(1334499539404)/",
            ChangedBy: "Marcus",
            IsPublished: true,
            IsDeleted: false,
            Slug: "slug",
            Url: "url",
            SortOrder: 0
        },
        Parent: null,
        Children: []
},
    Children: [
        {
            Heading: "Foo",
            MainBody: null,
            Id: "pages/226",
            Metadata: {
                Name: "I'm an article",
                Title: null,
                Keywords: null,
                Description: null,
                DisplayInMenu: true,
                Published: "/Date(1334511318838)/",
                Changed: "/Date(1334511318838)/",
                ChangedBy: "Marcus",
                IsPublished: true,
                IsDeleted: false,
                Slug: "i-m-an-article",
                Url: "i-m-an-article",
                SortOrder: 1
            },
            Parent: {},
            Children: [ ]
        },
        {
            Heading: "Bar",
            MainBody: null,
            Id: "pages/257",
            Metadata: {
                Name: "Foo",
                Title: null,
                Keywords: null,
                Description: null,
                DisplayInMenu: true,
                Published: "/Date(1334953500167)/",
                Changed: "/Date(1334953500167)/",
                ChangedBy: "Marcus",
                IsPublished: true,
                IsDeleted: false,
                Slug: "foo",
                Url: "foo",
                SortOrder: 2
            },
            Parent: {},
            Children: [ ]
        }
    ]
}

---

当看到上面的回答时，我确信答案是将这些数据合并到我的控制器中，而不是由它们自己获取对象和集合，但我仍然对第二种观点感到好奇

将你的收藏从一个收藏中分离出来并没有什么特别的错误。
但是，如果你正在构建一个单页应用程序（或者至少是一个具有高度动态内容的页面），请确保优化你的请求

我看到了很多可能出错的地方，但我也已经看到了正确的地方

您已将文章作为一个集合处理。
你没有你的身体在那里，但再一次，这可能是好的或坏的，取决于你想要实现什么

我可以告诉你，在同一个JSON响应中，下载20多篇500-1500字的文章，加上每个文章的评论，再加上上面所有文章的元数据/微数据，将与下载shell（用于“最新故事”小部件和文档树视图）一样痛苦，然后在自己的调用中获取每个文章的内容

但请考虑一下：这两件事都不符合休息的原则。 REST只是规定您应该传输状态，每个URL应该指向一个有意义的名词，并且您使用的HTTP动词应该指示对该名词所做的操作，以及如何将操作的结果反馈给客户端

REST并不是天生的超媒体。这不一定是关于将URL链接到每个数据子集的兔子洞，其中一个集合中的一个项目可能有一个指向另一个集合的项目的URL，而另一个集合可能有一个指向另一个集合的URL，为了显示一篇媒体丰富的博客文章，您需要访问其中的每一个项目以获取所需的所有数据

如果你有一个超媒体系统为你工作，恭喜你。
认真地如果你能自己写出来，那就太好了。
但是REST只是希望URL是唯一的，或者，如果是集合，则希望集合以可预测的方式返回，根据URL

那么，是什么阻止你产生一个集合，而这个集合恰好是其他事物的集合呢？REST不关心前端的解析，也不关心后端的集合。
或者，如果你坚持你当前的格式，考虑即时数据服务。 我的意思是：
如果我将最近10篇文章作为一个集合加载并显示它们，我会暂停获取任何评论，直到用户单击“显示更多”按钮，或向下滚动足够远以查看评论，等等，然后我只收集该特定文章的评论

前端的目标不是试图将所有请求限制为一个巨大的请求。
前端的目标是快速加载，即使它只是为了达到一个点，即你有几个小部件，上面写着“加载…”并让开，这样用户就可以尽快与那里的内容交互，并将用户看不见的内容流进来（无论是在计时器上流式传输，还是基于与按钮或事件的交互流式传输，等等）

这一切在REST中都是可行的，甚至在超媒体范例中也是可行的。

---

您只需要注意预先请求的数量。

您对这个合并响应所做的操作与将单个实体作为资源公开一样，也是RESTful的。