描述:
刚从web开发转到APP接口开发，遇到了一个问题：
在服务器向APP返回数据时，是否需要遵循‘只返回需要的字段’的习惯？
例如我们有个产品表，结构如下
|---ID---|--名称--|--链接--|--日利率--|--月利率--|--购买人数--|--成功率--|
在产品列表页面的时候，只需要ID,名称,链接这三个数据，其他字段在此页面不需要，那么服务器返回数据的时候，是否一定不能把其他在本页面不需要的字段暴露给APP?
如果每次都返回所有字段，后端这边会节省时间和代码量。但是如果返回所有，由于一个表60+的字段，对网络请求和相应速度有影响。
补充一下，该数据在多个地方都在用，每个地方所需要的字段都不太一样，如果从复用的角度看，几乎就是需要返回所有字段。。那么是选择返回所有以便于复用还是每个接口单独设计接口返回字段呢？
解决方案1:
按需返回，合并求情，多场景复用。
正常情况下全部使用别名返回，不能暴露数据库字段。
我觉得看客户端是否需要做请求合并了，其实你担心的只是几个字节的事情，你又没有在链接中返回图片等流数据，不要太考虑流量的问题，往往客户端的消耗都是在多次建立和服务端的链接上。
解决方案3:个人觉得，后端一般不应该直接返回数据库字段，最好是仅暴漏需要的数据。
后端直接返回数据库字段是很偷懒的做法，如果是内部使用的web后台，数据库也不复杂，返回的数据也不被多个客户端使用，可以这么做，优点是简单快速。其他情况应该都不应该，比如表字段很多，查询所有字段会降低性能；给终端用户调用的API，如果直接返回表结构可能会暴漏一些敏感信息；有多个客户端调用的API(web, ios, android, 第三方用户等)，需要设计良好的数据结构。
其实后端框架的ORM一般都可以限制返回的字段，也可以alias字段名，在Model中简单写几行代码就可以做搞定。如果需要更好的控制返回字段，应该使用transformer：
php: Fractal
python: marshmallow
ruby: ActiveModel Serializers
虽然没听过遵循，但是我觉得，按需返回是减少IO最好的方式。不仅用户体验好，服务器压力也小。
依照情况而定吧
看这个接口的复用情况：如果一个接口在多处复用，但是响应的数据结构差别不大，那就都返回即可
理论上返回的数据量越少越好
这个也太费流量了吧，用户会不爽的。
数据库不是有View么，你在产品表的基础上给它套上一个View，只显示需要的字段。
SQL什么的复制粘贴、替换表名为View的名字（然后删掉SQL语句里不需要的字段）就差不多可以了。
真心不怎么费时间，代码也不需要做太大更改。这种只遮盖字段的View速度跟飞一样，几乎不会影响服务器性能。