An established communications company is beginning its API-led connectivity journey, The company has been using a successful Enterprise Data Model…

Experience APIs are designed to serve a specific client application or channel, such as a mobile app. Their primary purpose is to provide data in a format that is optimized and simplified for that specific consumer. This often requires reconfiguring, aggregating, or transforming data from underlying Process and System APIs. Therefore, the data model of the Mobile Account Management EAPI is dictated by the needs of the mobile app, not directly by the canonical Enterprise Data Model (EDM). The EAPI consumes data that originates from the EDM via lower-level APIs but presents it in a purpose-built, non-canonical format.

A. Customer SAPI: System APIs are designed to expose core backend systems and data. They are the ideal layer to implement and expose entities according to the canonical Enterprise Data Model for enterprise-wide consistency and reuse.

B. Customer Lookup PAPI: Process APIs compose and orchestrate calls to System APIs. Their data models are typically derived directly from the canonical models exposed by the System APIs they consume, thus being served by the EDM.

D. Service SAPI: Similar to the Customer SAPI, this System API exposes a core business entity. It should conform to the Enterprise Data Model to ensure a consistent, reusable representation of a "Service" across the organization.

1. MuleSoft Documentation, "API-led Connectivity": This foundational document explains the roles of the three API layers. It states that Experience APIs are "purpose-built for a specific audience or context" and "reconfigure this data for ease of consumption by their intended audience." This supports the concept that their data models are client-specific, not canonical. (Source: MuleSoft Docs, API-led Connectivity Whitepaper).

2. MuleSoft Documentation, "Designing APIs": In the section on API design principles, it is often emphasized that System APIs should expose a canonical representation of data sources, while Experience APIs are tailored for consumption. "The purpose of an Experience API is to provide a fit-for-purpose API that is designed from the perspective of its consumer." (Source: MuleSoft Docs, About API Design).

3. MuleSoft Catalyst Knowledge Hub, "Domain Driven Design and Bounded Contexts": This resource explains that System APIs often align with core domains and their canonical models. In contrast, Experience APIs serve specific use cases, which may require a different, non-canonical view of the data. (Reference: MuleSoft Catalyst Knowledge Hub, Architectural Patterns section).