刚从web开发转到APP接口开发，遇到了一个问题：
在服务器向APP返回数据时，是否需要遵循‘只返回需要的字段’的习惯？
例如我们有个产品表，结构如下
|---ID---|--名称--|--链接--|--日利率--|--月利率--|--购买人数--|--成功率--|
在产品列表页面的时候，只需要ID,名称,链接这三个数据，其他字段在此页面不需要，那么服务器返回数据的时候，是否一定不能把其他在本页面不需要的字段暴露给APP?
如果每次都返回所有字段，后端这边会节省时间和代码量。但是如果返回所有，由于一个表60+的字段，对网络请求和相应速度有影响。
补充一下，该数据在多个地方都在用，每个地方所需要的字段都不太一样，如果从复用的角度看，几乎就是需要返回所有字段。。那么是选择返回所有以便于复用还是每个接口单独设计接口返回字段呢？
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Retournez si nécessaire, fusionnez et intercédez, et réutilisez dans plusieurs scénarios.
Dans des circonstances normales, tous les retours sont renvoyés à l'aide d'alias et les champs de la base de données ne peuvent pas être exposés.
Cela consomme trop de trafic et les utilisateurs seront mécontents.
La base de données n'a-t-elle pas de vue ? Vous y ajoutez une vue basée sur la table des produits et affichez uniquement les champs obligatoires.
Copiez et collez SQL ou quelque chose du genre, remplacez le nom de la table par le nom de View (puis supprimez les champs inutiles dans l'instruction SQL) et c'est presque suffisant.
Cela ne prend vraiment pas beaucoup de temps et le code n’a pas besoin d’être beaucoup modifié. Ce type de vue qui couvre uniquement les champs est aussi rapide que le vol et n'affectera guère les performances du serveur.
Cela dépend de la situation
Regardez la réutilisation de cette interface : si une interface est réutilisée à plusieurs endroits, mais que la structure des données de réponse n'est pas très différente, renvoyez-les simplement toutes
Théoriquement, plus la quantité de données renvoyées est petite, mieux c'est
Même si je n'en ai pas entendu parler
遵循, je pense que le retour à la demande est le meilleur moyen de réduire les IO. Non seulement l’expérience utilisateur est bonne, mais la pression sur le serveur est également moindre.Personnellement, le backend ne doit généralement pas renvoyer directement les champs de la base de données. Il est préférable d'exposer uniquement les données requises.
Il est très paresseux pour le backend de renvoyer directement les champs de la base de données. S'il s'agit d'un backend Web utilisé en interne, la base de données n'est pas compliquée et les données renvoyées ne sont pas utilisées par plusieurs clients. que c'est simple et rapide. D'autres situations ne doivent pas être utilisées. Par exemple, s'il existe de nombreux champs de table, l'interrogation de tous les champs réduira les performances ; les API appelées vers les utilisateurs finaux peuvent divulguer certaines informations sensibles si elles renvoient directement la structure de la table appelée par plusieurs clients (Web, ios, android, utilisateurs tiers, etc.), une structure de données bien conçue est requise.
En fait, le
ORMdu framework back-end peut généralement limiter les champs renvoyés, ou vous pouvezaliasle nom du champ Écrivez simplement quelques lignes de code dansModelpour le faire. Si vous avez besoin d'un meilleur contrôle sur les champs renvoyés, vous devez utiliser transformer :php : Fractale
python : guimauve
ruby : sérialiseurs ActiveModel
Je pense que cela dépend si le client a besoin de fusionner les demandes. En fait, ce qui vous inquiète, ce ne sont que quelques octets, et vous ne renvoyez pas de données en streaming telles que des images dans le lien. sur les problèmes de trafic, qui sont souvent consommés par le client, tous sont basés sur l'établissement de liens avec le serveur à plusieurs reprises.
La meilleure méthode est la suivante :
1. Les noms de colonnes qui doivent être renvoyés sont fournis par le front-end
2 L'interface côté serveur est écrite de manière universelle et le SQL est épissé. selon les noms de colonnes fournis par le front end
ps : Bien que cette conception soit gênante au début, elle est très pratique pour l'expansion des fonctions à un stade ultérieur