As we have already seen with the published interfaces, it is now important to define the content of these endpoints and their size.
An important topic that is not always addressed is the componentization of the endpoints that are exposed. Think about a microservice responsible for user information. Some development teams decided to create a large endpoint that provides all possible information stored about a user. This type of endpoint, one getUser type, may seem simple for development, but not for scalability.
A great deal of useless information for those who consume the API may be being passed, or is heavily specific information to transmit and expensive to be generated by the microservice. Thinking practically, the most sensible approach is to create an information API more fragmented and diverse, and if a getUser is necessary, create an orchestrator of the smaller information and pass on a single endpoint. The following diagram is a good example of this:
This type of strategy is called endpoint builder, where the heavy point of information actually is compositions of other lighter data sources.
