假设您有一个使用Web Api项目构建的Recipe Manager应用程序。您是否在JSON中发送食谱列表及其成分名称？或者您是否发送食谱，成分名称和成分详细信息？确定SPA的初始有效载荷有多大的过程是什么？
答案 0 :(得分：12)
这些是在初始页面中向客户端发送多少内容的决定因素：
在显示食谱列表的食谱页面上，我会得到食谱和一些可以显示的关键因素（如食谱名称，菜肴和其他关键信息）。足以让用户确定要选择的内容。然后当用户潜入食谱时，去获取该食谱的详细信息。
一般规则是获得用户几乎肯定需要的东西。然后在他们请求时获取其他数据。
答案 1 :(得分：6)
确定要发送多少数据的过程取决于您希望为用户提供的体验 - 但这很简单。如果我的经验要求我很容易地用简短的描述显示所有的食谱然后让他们钻进食谱以获得更多信息，那么我只将发送足够的信息来产生显示并进一步导入实体。
如果在导航到配方后，它需要您显示配料名称和度量，然后发送该信息和足够的信息以进一步导入任何单一成分。
正如你所看到的那样，它一直在继续。
答案 2 :(得分：4)
这取决于您的应用程序是否只是支持您的网页的简单HTTP API，或者您的目标更类似于平台即服务。采用SPA的一个驱动因素是它使浏览器成为另一个客户端，就像iOS或Android应用程序或第三方一样。
如果您想支持多个客户端，那么您可能希望围绕您尝试公开的资源设计API，以便您可以使用GET / POST / PUT等统一接口来对付该资源。这意味着您更有可能不以客户特定的方式编码，并且您的API可供各种客户使用。
资源就是你想要拥有自己的URN的任何东西。
我建议在这种情况下，您可能需要一个食谱书资源，该资源包含指向各个食谱资源的链接，这些资源可能包含该食谱所需的所有信息。如果您对成分所含的内容有更深入的了解，并且他们拥有自己的资源，那么成分将只是一个单独的资源。
在Huddle，我们使用文档驱动设计方法。那就是我们预先为我们的API编写文档，以便我们了解API的可用性。您可以测量WTF中的API质量。 http://code.google.com/p/huddle-apis/
现在，这种逻辑划分在性能方面可能不是最佳的。您在API的可用性和API的性能之间处理经典的权衡（最终架构是关于平衡设计权衡）。通常，在您知道这是一个问题之前不要偏向性能，因为您将在可用性或可维护性方面为早期优化付出代价。
答案 3 :(得分：0)
另一种可能性是为WebAPI实现OData查询支持。 http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api
这样，您的客户可以执行自己的查询，只返回他们需要的数据。