A customer opens an order. They expect a total, purchased items, payment status and delivery date. Inside the company, these may belong to four different teams and services. The customer needs one understandable screen, not a guided tour of the backend architecture.
If the mobile app calls every internal service directly, it has to understand their endpoints, errors and independent changes. That may be called microservice independence on an architecture diagram. To the client team it often looks like doing somebody else's integration work.
Compose the product response on the server
API Composition moves the assembly work to a dedicated component. The client asks for an order view; the composition layer requests data from the relevant internal services, combines it and returns a contract shaped for that screen or external consumer.
Some calls can run in parallel, reducing the time a client spends waiting across several network round trips. This can matter on mobile connections. But the internal dependencies have not disappeared. They are now hidden behind a more useful product boundary.
Composition may live in a Backend for Frontend, a dedicated aggregator or sometimes an API Gateway. Heavy business orchestration should not automatically become part of the central routing path for every request. The more that central component owns, the more disruptive its failure becomes.
One dependency failed. What does the customer see?
Suppose product recommendations are unavailable on the order page. Annoying, but checkout can continue. Now suppose payment confirmation is missing. Pretending the order is complete would be a very different kind of failure.
The composition layer needs an explicit distinction between required and optional information. Sometimes a partial response with a clear missing-data state is appropriate. Other times the whole operation must fail rather than make a promise the system cannot verify.
Deadlines, concurrency limits, tracing of each downstream call and considered fallback behaviour are important. Otherwise one slow dependency holds up the entire response, and troubleshooting becomes guesswork.
Nor does stitching several responses together provide a consistent snapshot automatically. Payment and shipping may have been queried at different moments. If one atomic view is a hard business requirement, API Composition alone cannot guarantee it.
Who owns the customer-facing contract?
The organisation can recreate the bottleneck it was trying to remove. Clients no longer know the internal services, but every product change now needs approval from the central aggregation team. Seven APIs become one waiting line.
I would define who owns the external contract, who can change the response and who decides which information is optional during an incident. The aggregator should not quietly take over domain rules such as discounts, refund permissions or payment confirmation.
When another layer is not worth it
If a screen uses one service and a few fields, a separate composition layer adds little. If the problem is merely several queries to one backend, a better endpoint may be sufficient. Measure actual client latency, duplicated orchestration code and coordination overhead before introducing a new component.
The Gateway Aggregation pattern from Azure Architecture Center covers similar trade-offs around parallel calls, timeouts, partial responses and the cost of an intermediary.
API Composition earns its keep when the customer gets a coherent journey and the company can change internal services without dragging every client along. But hiding complexity is not removing it: somebody still has to operate it and own the outcome.