Php 从RESTAPI构建复杂页面

我正在开发一个带有PHP Rest API后端和Angular JS前端的应用程序。我想说的是使用多个模型的数据呈现页面的最佳实践。例如，如果要显示“人员”资源的详细信息页面，则很容易获取与该人员相关的所有数据。但是，如果您还需要一个侧边栏，显示已上载的与此人相关的文档数量以及已创建的关于此人的注释数量，您将如何操作？在更传统的应用程序中，您可以将所有相关数据收集在控制器中，然后将其注入要返回的视图中，但在同一次调用中返回描述此人的数据以及文档和便笺计数等外围数据，这难道不是与RESTful方法相反吗？是否应将这些设置为多个api调用，以从数据库中获取不同的数据对象？在考虑后一个选项时，有多少单独调用一个api以构建单个视图被认为是可以接受的

冷酷的事实是，客户机需要有数据来显示它，不管它以何种方式到达那里是RESTful还是非RESTful。我在99.9999999%的时间里非常喜欢RESTful方法，但也有几次发现它不太合适。不过，在这种情况下，我认为它确实合适

您所描述的内容听起来可以通过将与此人相关的文档、注释、注释、小部件等的总数存储在此人的实际模型中并根据需要进行更新来实现。根据项目的规模，这可能是必要的。一个请求就可以收集所有这些信息，不会感到尴尬，还可以为您节省大量客户端工作

---

另一种方法是做一些$watching或其他事件驱动的请求来获取每种资源类型的列表，这……如果你只是进行计数，那么大部分时间的效率会更低。

我在构建我的第一个Angular应用程序时也遇到了同样的问题。RESTful方法不是一种一刀切的体系结构风格……通常需要一些偏差才能实现最终结果。使用Angular可以相当容易地将这些操作分离到它们自己的控制器和服务提供者中，从而在这方面实现关注点的分离

---

如果最终用户可以独立创建注释和上传文档，那么我会将它们作为单独的资源保存。如果不是，那么一次呼叫也不是坏事。

不应该像total uploaded那样符合，并且在常规RESTful布局中创建的total notes是用户资源的一部分吗？为了更详细地了解我的设置，人员数据存储在subjects表中，notes表中的notes和documents表中的documents。这个应用程序目前是一个完全服务器端的codeigniter应用程序，所以所有这些表都有自己的模型。我担心的是，当我真的试图请求特定主题的详细信息时，默认情况下，是否不适合从其他两个间接模型返回数据，因为主要原因是支持特定的实现，即当前应用程序的视图。这是否会削弱api的通用性，使其能够在不继承数据开销的情况下被其他应用程序使用，而数据开销与另一个应用程序的实现紧密相连。如果我理解正确，您的问题是是否可以将请求中的注释和文档信息发送回主题资源url？我经常在API中看到这种情况。如果您请求/api/subjects/123，它可能会返回如下内容：{id:123，name:Bob，documents:[]，notes:[]}您没有理由不能同时实现/api/documents/:id和/api/notes/:id以使api继续保持通用性。当然，在主题中包含文档和注释不会有什么坏处，除非问题是数据量。如果问题是数据量，返回这样的计数就足够了，因为某种原因，我觉得您只是在页面上显示每个资源的计数。对不起，如果我弄错了。{id:123，name:Bob，documents:12，notes:88}该应用程序目前是一个服务器端codeigniter应用程序，每个表subject、note、document都由一个单独的模型subject、notes、documents提供服务。每个视图都可以独立上传，但有些视图将各种数据收集在一起。在考虑将它们作为单独的调用时，问题出现了，在客户端呈现单个视图时，有多少对api的单独调用是典型的或可接受的？我不认为对单个视图的典型或可接受的api调用有一个阈值…这一切都取决于应用程序。以微软的Azure门户为例；这是一个SPA，在任何给定的m上，页面上至少有10个小部件 预兆每一个都获取特定的数据。您必须考虑最大并发请求的浏览器限制。当遇到更高的api调用计数时，还必须考虑服务器基础结构。对于100个用户来说，一个api调用并不坏，但是对于100个用户来说，10个api调用会带来10倍的差异。