刚从web开发转到APP接口开发，遇到了一个问题：
在服务器向APP返回数据时，是否需要遵循‘只返回需要的字段’的习惯？
例如我们有个产品表，结构如下
|---ID---|--名称--|--链接--|--日利率--|--月利率--|--购买人数--|--成功率--|
在产品列表页面的时候，只需要ID,名称,链接这三个数据，其他字段在此页面不需要，那么服务器返回数据的时候，是否一定不能把其他在本页面不需要的字段暴露给APP?
如果每次都返回所有字段，后端这边会节省时间和代码量。但是如果返回所有，由于一个表60+的字段，对网络请求和相应速度有影响。
补充一下，该数据在多个地方都在用，每个地方所需要的字段都不太一样，如果从复用的角度看，几乎就是需要返回所有字段。。那么是选择返回所有以便于复用还是每个接口单独设计接口返回字段呢？
按需返回，合併求情，多場景復用。
正常情況下全部使用別名返回，不能暴露資料庫欄位。
這個也太費流量了吧，用戶會不爽的。
資料庫不是有View麼，你在產品表的基礎上給它套上一個View，只顯示需要的欄位。
SQL什麼的複製貼上、替換錶名為View的名字（然後刪掉SQL語句裡不需要的欄位）就差不多可以了。
真心不怎麼花時間，程式碼也不需要做太大更改。這種只遮蓋欄位的View速度跟飛一樣，幾乎不會影響伺服器效能。
依情況而定吧
看這個介面的複用情況：如果一個介面在多處復用，但是回應的資料結構差異不大，那就都回傳即可
理論上回傳的資料量越少越好
雖然沒聽過
遵循，但是我覺得，按需返回是減少IO最好的方式。不只使用者體驗好，伺服器壓力也小。個人覺得，後端一般不應該直接返回資料庫字段，最好是僅暴漏需要的資料。
後端直接回傳資料庫欄位是很懶的做法，如果是內部使用的web後台，資料庫也不複雜，回傳的資料也不被多個客戶端使用，可以這麼做，優點是簡單快速。其他情況應該都不應該，例如表格欄位很多，查詢所有欄位會降低效能；給終端使用者呼叫的API，如果直接回傳表結構可能會暴漏一些敏感資訊；有多個客戶端呼叫的API(web, ios, android, 第三方使用者等)，需要設計良好的資料結構。
其實後端框架的
ORM一般都可以限制返回的字段，也可以alias字段名，在Model中簡單寫幾行程式碼就可以做搞定。如果需要更好的控制返回字段，應該使用transformer：php: Fractal
python: marshmallow
ruby: ActiveModel Serializers
我覺得看客戶端是否需要做請求合併了，其實你擔心的只是幾個字節的事情，你又沒有在鏈接中返回圖片等流數據，不要太考慮流量的問題，往往客戶端的消耗都是在多次建立和服務端的連結上。
最好的方法就是:
1.需要傳回的列名由前端來提供
2.服務端的介面寫成通用的,根據前端提供的列名來拼接sql
ps:這個設計雖然前期麻煩,但到後期的功能拓展什麼的非常方便