刚从web开发转到APP接口开发，遇到了一个问题：
在服务器向APP返回数据时，是否需要遵循‘只返回需要的字段’的习惯？
例如我们有个产品表，结构如下
|---ID---|--名称--|--链接--|--日利率--|--月利率--|--购买人数--|--成功率--|
在产品列表页面的时候，只需要ID,名称,链接这三个数据，其他字段在此页面不需要，那么服务器返回数据的时候，是否一定不能把其他在本页面不需要的字段暴露给APP?
如果每次都返回所有字段，后端这边会节省时间和代码量。但是如果返回所有，由于一个表60+的字段，对网络请求和相应速度有影响。
补充一下，该数据在多个地方都在用，每个地方所需要的字段都不太一样，如果从复用的角度看，几乎就是需要返回所有字段。。那么是选择返回所有以便于复用还是每个接口单独设计接口返回字段呢？
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
必要に応じて戻り、マージして仲介し、複数のシナリオで再利用します。
通常の状況では、すべての戻り値はエイリアスを使用して返され、データベース フィールドを公開することはできません。
これはトラフィックを大量に消費するため、ユーザーは不満を感じるでしょう。
データベースにはビューがありませんか? 製品テーブルに基づいてデータベースにビューを追加し、必要なフィールドのみを表示します。
SQL などをコピペし、テーブル名を View の名前に置き換える（SQL 文内の不要なフィールドを削除する）だけでほぼ十分です。
実際にはそれほど時間はかかりませんし、コードを大きく変更する必要もありません。フィールドのみをカバーするこの種の View は飛行するのと同じくらい速く、サーバーのパフォーマンスにはほとんど影響しません。
状況によります
このインターフェースの再利用を見てください: インターフェースが複数の場所で再利用されているが、応答データ構造に大きな違いがない場合は、それらをすべて返します
理論的には、返されるデータの量が少ないほど優れています
聞いたことはありませんが
遵循、オンデマンドで返すのが IO を削減する最良の方法だと思います。ユーザーエクスペリエンスが優れているだけでなく、サーバーの負荷も低いです。個人的には、バックエンドは通常、データベース フィールドを直接返すべきではなく、必要なデータのみを公開することが最善です。
バックエンドがデータベース フィールドを直接返すのは非常に手間がかかります。内部で使用される Web バックエンドの場合、データベースは複雑ではなく、返されたデータは複数のクライアントで使用されません。それはシンプルで速いということです。他の状況では使用しないでください。たとえば、多数のテーブル フィールドがある場合、すべてのフィールドをクエリすると、エンド ユーザーに呼び出される API が複数のクライアント (Web、Web、 iOS、Android、サードパーティ ユーザーなど）、適切に設計されたデータ構造が必要です。
実際、バックエンド フレームワークの
ORMは通常、返されるフィールドを制限できます。または、aliasに数行のコードを記述するだけでフィールド名を制限できます。返されるフィールドをより適切に制御する必要がある場合は、Modeltransformer: を使用する必要があります。実際に心配するのはクライアントがリクエストをマージする必要があるかどうかによると思いますが、リンクに画像などのストリーミングデータを返す必要はありません。クライアントによって消費されることが多いトラフィックの問題については、すべてサーバーとのリンクを複数回確立することに基づいています。
最良の方法は次のとおりです:
1. 返される必要がある列名はフロントエンドによって提供されます
2. サーバー側のインターフェイスはユニバーサルなものとして記述され、SQL は結合されます。フロントエンドによって提供される列名による
ps: この設計は初期段階では面倒ですが、後の段階での機能拡張には非常に便利です