后端再开发APP接口时，例如是一个电商型的APP，那个在个人中心的页面上会有用户的个人资料，用户的购物车数量，用户的余额信息，推荐的商品等等的一些相关的东西，那么对于接口来说，是应该在APP的一次请求中返回页面包含的所有内容？还是应该针对资源让APP多次请求获取？如果应该一次性请求的且接口为RESTFul风格的话要如何设计请求及返回内容更加合理？
补充一下，减少网络请求我固然知道是对网络而言是更好的，但是在减少网络请求的同时必然会造成请求内容过大，用户等待时间可能更长，而且在RESTFul风格的API下，如何设计会更加合理？
个人人为并且实践中都是使用多次请求，这样能保证app的灵活性，便于服务端分模块开发，还保证了可维护性。而且大部分时候，加载一些用户不常用的数据反而浪费了用户流量。
当然需要分开了，app用异步请求，可以先加载一些数据，根据等级来分
一般建议尽可能少的网络请求。但对于一些及时性要求不高的数据，可以采用本地缓存，比如个人资料。
看你现在服务架构的复杂程度：
集中的话：方便就行，根据当前的服务规模（创业公司）
分布的话：不同的数据来自不同的服务接口（成熟公司）
补充：电商就是不断的重构，重构就是解耦，解耦就是面向接口的编程
楼上的回答都很好,补充下,楼主可以看看redis的pipeline设计,比如用户基本资料,购物车这些信息在一个主页面都需要显示的化,可以在同一个http请求,发送多个命令,然后服务器端逐个返回内容.
服务器端设计当然要分模块化设计最好,那么这种批量命令请求方式后端可能需要一个接收命令的模块了,来分析命令,然后委托到实际的模块得到结果.
如果题主懂一些网络请求方面的话，应该知道，在用户信息不大的情况下，一次性的请求所有的用户信息是比较好的。因为连接的损耗是必然的。
可以对业务做下数据筛选，例如跟钱有关的或者跟商品数量有关的，请求频率可以高一些，例如个人资料该前端缓存的可以适当的做一些策略判断是读缓存还是服务器重新获取…不能一次全部获取，全部缓存，也不能过于频繁的发起请求。
既然问的是RESTful的API，那自然是按资源的类型来分，而不是按页面分。也就是说你在设计API的时候不用去考虑客户端是如何组织资源的，而是依据你们服务器端的数据库架构。一般来说，一张表对应一个Model，一个Model对应一个请求。当然实际项目中有时候会有些特殊需求，我会做些变动，不一定严格按照这样的模式。
也一直有这个疑问，根据资源来说，app页面变化后基本上没有太大影响，如果跟着页面来的话，只要产品那边一说要改，那以前的接口基本就没啥用了。 不过客户端的一些小伙伴喜欢根据页面来的
看接口的语义来选择吧，我感觉这种问题应该没有统一的答案，你们自己爽了就ok了