@gdtv 这个应该属于两种风格吧，我们这边跟你们那恰恰相反，服务端希望每个页面一个接口，我是客户端，我希望每个都单独起来比较好。
你说的这种情况，我觉得应付简单的需求变更比较好，假如需求变更频繁，也比较麻烦。我们这边，APP 每个页面，都基本上要重新做个 3,4 遍....

@gdtv 我做的项目，基本上都是分成多个接口来处理的。
分成多个接口来处理，
优点：
1.更好的能适应需求变更。例如首页要显示信息 a,b,c，结果下个需求，c 不要在首页中显示，移到其他页面了。这样的话，接口都不需要动。假如接口按照页面给的话，要改两个接口。服务端，客户度都要动，还要重新联调。
2.接口按页面给出，对一些数据量比较大的页面，很可能出现一个接口，数据很大的情况。可能性能上，会比较麻烦。
3.很多分页加载的列表，也只能按接口给出列表需要的数据，不可能一次性把页面上的数据都全部一次性给出。
4.有利于客户端做部分数据缓存的工作。
缺点：
1.就是为了加载一个页面，可能要加载很多接口，导致页面加载速度有点慢。这个我们都是靠优化来解决，有些数据的获取，可以放在登录、APP 初始化的时候，数据量比较小的页面，分担一些通用数据获取的工作。有些不常更改的数据，可以直接通过版本控制的方式，缓存在客户端。
2.部分数据接口之间，有依赖关系。这个也要处理好。

@neoblackcap 我看的材料，都是 ModelSerializer 对 Model 进行序列化，然后 ModelViewSet 中，通过 queryset 和 serializer 来返回数据。例如：
queryset = Article.objects.all()
serializer_class = ArticleSerializer

给我的感觉是一个 ModelViewSet 只对应一个 Model，把干这个 Model 序列化后返回给客户端就完事了。
但是一般的 APP 接口逻辑不可能只是获得这样的模型对象的，例如登录，我要从客户端传入 username 和 pwd，进行验证，可能还要查询、设置其他表一些标志位，形成 user 的数据，返回给客户端。这样的逻辑处理，和涉及好几个表之间的操作，在 django rest framework 中，怎么操作呢？

@virusdefender 烦请详述

@neoblackcap 感谢您的回答，不过我问题其实是关于 django-rest-framework 是否是用便捷程度的问题，我目前对 restful 风格还是有些陌生，不知道逻辑处理怎么在 rest 框架中体现，想直接用 django 返回 json 数据，但是看到大家都在推荐 rest 写 api 接口，所以比较困惑。

怎么讲授，取决于你们两个之间的关系...

电脑里安装了一个鲁大师，连电源管理都被替换成 360 的方案了，我也是醉了，提示都不带提示的，不知道还给电脑安装了什么...