asp.net-mvc - 您如何决定在单页应用程序中向用户推送多少数据？

Question

假设您有一个使用 Web Api 项目构建的 Recipe Manager 应用程序。您是否以 JSON 格式发送食谱列表及其成分名称？或者您是否发送食谱、成分名称和成分详细信息？确定 SPA 的初始有效负载应该有多大的过程是什么？

score 12 · Accepted Answer

这些是在初始页面中向客户端发送多少的决定因素：

在将显示食谱列表的食谱页面上，我将获取可显示在列表中的食谱和一些要显示的关键因素（如食谱名称、菜肴和其他关键信息）。足以让用户决定选择什么。然后当用户潜入一个食谱时，然后去获取那个 1 食谱的详细信息。

一般规则是获得用户几乎肯定需要的东西。然后根据他们的要求获取其他数据。

score 6 · Accepted Answer

您确定要发送多少数据的过程完全取决于您希望为用户提供的体验——然而它就是这么简单。如果我的经验要求我很容易地显示所有带有简短描述的食谱，然后允许他们深入研究食谱以获取更多信息，那么我只会发送足够的信息来生成显示并进一步导航到实体中.

如果在导航到配方后，它要求您显示成分名称和度量，然后发送该信息和足够的信息以进一步导航到任何单一成分。

正如你所看到的，它一直在继续。

score 4 · Accepted Answer

这取决于您的应用程序是否只是支持您的网页的简单 HTTP API，或者您的目标是更类似于平台即服务的东西。采用 SPA 的一个驱动因素是它使浏览器成为另一个客户端，就像 iOS 或 Android 应用程序或第 3 方一样。

如果您想支持多个客户端，那么您可能希望围绕您尝试公开的资源设计您的 API，以便您可以针对该资源使用 GET/POST/PUT 等统一接口。这意味着您更有可能没有以特定于客户端的样式进行编码，并且您的 API 将被广泛的客户端使用。

资源是您希望拥有自己的 URN 的任何东西。

我建议在这种情况下，您可能需要一个食谱书资源，该资源具有指向各个食谱资源的链接，这些资源可能包含该食谱所需的所有信息。如果您对成分所包含的内容有更深入的了解并且他们拥有自己的资源，那么成分只会是一个单独的资源。

在 Huddle，我们使用文档驱动设计方法。也就是说，我们预先为我们的 API 编写文档，以便我们了解我们的 API 的可用性。您可以测量 WTF 中的 API 质量。http://code.google.com/p/huddle-apis/

现在，就性能而言，这种逻辑划分可能不是最佳的。您在 API 的可用性和 API 的性能之间处理一个经典的权衡（最终架构就是平衡设计权衡）。通常，在您知道这是一个问题之前不要偏爱性能，因为您将在可用性或可维护性方面为早期优化付出代价。

score 0 · Accepted Answer

这样，您的客户可以执行他们自己的查询以仅返回他们需要的数据。

4 回答 4