android - APP接口开发的字段暴露问题

Question

刚从web开发转到APP接口开发，遇到了一个问题：
在服务器向APP返回数据时，是否需要遵循‘只返回需要的字段’的习惯？
例如我们有个产品表，结构如下
|---ID---|--名称--|--链接--|--日利率--|--月利率--|--购买人数--|--成功率--|

在产品列表页面的时候，只需要ID,名称,链接这三个数据，其他字段在此页面不需要，那么服务器返回数据的时候，是否一定不能把其他在本页面不需要的字段暴露给APP?

如果每次都返回所有字段，后端这边会节省时间和代码量。但是如果返回所有，由于一个表60+的字段，对网络请求和相应速度有影响。

---

补充一下，该数据在多个地方都在用，每个地方所需要的字段都不太一样，如果从复用的角度看，几乎就是需要返回所有字段。。那么是选择返回所有以便于复用还是每个接口单独设计接口返回字段呢？

Answer 1

Return as needed, merge and intercede, and reuse in multiple scenarios.
Under normal circumstances, all returns are returned using aliases, and database fields cannot be exposed.

Answer 2

This consumes too much traffic, and users will be unhappy.

Don’t the database have a View? You add a View to it based on the product table and only display the required fields.

Copy and paste SQL or something, replace the table name with the name of View (and then delete the unnecessary fields in the SQL statement) and it's almost enough.

It really doesn’t take much time, and the code doesn’t need to be changed much. This kind of View that only covers the fields is as fast as flying and will hardly affect server performance.

Answer 3

It depends on the situation

• Look at the reuse of this interface: If an interface is reused in multiple places, but the response data structure is not very different, then just return them all

• Theoretically, the smaller the amount of data returned, the better

Answer 4

Although I have never heard of it遵循, I think returning on demand is the best way to reduce IO. Not only the user experience is good, but the server pressure is also low.

Answer 5

Personally, I feel that the backend should generally not return database fields directly. It is best to only expose the required data.

It is very lazy for the backend to directly return database fields. If it is a web backend used internally, the database is not complicated, and the returned data is not used by multiple clients. You can do this. The advantage is that it is simple and fast. Other situations should not be used. For example, if there are many table fields, querying all fields will reduce performance; APIs called to end users may leak some sensitive information if they directly return the table structure; APIs called by multiple clients (web, ios, android, third-party users, etc.), a well-designed data structure is required.

In fact, it can be done by simply writing a few lines of code in the back-end framework ORM一般都可以限制返回的字段，也可以alias字段名，在Model. If you need better control over the return fields, you should use transformer:

• php: Fractal

• python: marshmallow

• ruby: ActiveModel Serializers

Answer 6

I think it depends on whether the client needs to merge requests. In fact, what you are worried about is only a few bytes, and you do not return streaming data such as pictures in the link. Don’t think too much about the traffic issue. Often the client’s consumption is all Establish multiple connections to the server.

Answer 7

The best way is:
1. The column names that need to be returned are provided by the front end
2. The server-side interface is written as a universal one, and the sql is spliced ​​according to the column names provided by the front end

ps: Although this design is troublesome in the early stage, it is very convenient for function expansion in the later stage