I personally use multiple requests artificially and in practice. This ensures the flexibility of the app, facilitates server-side sub-module development, and ensures maintainability. And most of the time, loading some data that users don't commonly use wastes user traffic.

Of course it needs to be separated. The app uses asynchronous requests. You can load some data first and divide it according to the level

It is generally recommended to make as few network requests as possible. However, for some data that does not require high timeliness, local caching can be used, such as personal data.

It depends on the complexity of your current service architecture:
If it is centralized: it is convenient, according to the current service scale (startup company)
If it is distributed: different data comes from different service interfaces (mature company) )

Supplement: E-commerce is constant reconstruction, reconstruction is decoupling, and decoupling is interface-oriented programming

The answers above are all very good. In addition, the author can take a look at the pipeline design of redis. For example, basic user information and shopping cart information need to be displayed on a main page. They can be made in the same http request. Send multiple commands, and then the server returns the content one by one.

Of course the server-side design must be modularized, so the backend of this batch command request method may need a module to receive commands to analyze the commands and then delegate it to the actual module to get the results.#🎜🎜 #

If the questioner knows something about network requests, he should know that when the user information is not large, it is better to request all user information at once. Because connection loss is inevitable.

You can filter the data for the business, for example, it is related to money or the quantity of goods. The request frequency can be higher. For example, the front-end cache of personal data can use some appropriate strategies to determine whether to read the cache or re-obtain it from the server...No Get them all at once, cache them all, and don't make requests too frequently.

Four words

微服务化

Since you are asking about RESTful APIs, it is natural to classify them by resource type, not by page. That is to say, when you design the API, you don't have to consider how the client organizes resources, but based on the database structure of your server. Generally speaking, a table corresponds to a Model, and a Model corresponds to a request. Of course, sometimes there are some special needs in actual projects, and I will make some changes, which may not strictly follow this model.

I have always had this question. According to the resources, the change of the app page will basically not have much impact. If it follows the page, as long as the product side says it needs to be changed, the previous interface will be basically useless. However, some friends on the client side like to follow the page

Choose based on the semantics of the interface. I feel that there is no unified answer to this kind of question. It’s ok if you feel comfortable with it