API-led connectivity layers and API boundaries
How to lay out System, Process and Experience APIs for a real application network: when a layer is justified, when it is not, how bounded contexts set API boundaries, and why the API model stays the maintained contract.
Create high-level integration architectures using API-led Connectivity.
~7 min read · 5 practice questions
What the exam expects
- Assign each capability to the System, Process or Experience layer from what it actually does, not from the diagram you started with.
- Decide when an extra layer is justified (adapting a native backend API) and when it is waste (a pass-through that changes nothing).
- Recognize that non-HTTP capabilities, such as a scheduled file transfer, can still be part of an API-led design.
- Derive API boundaries from the business domain model and its bounded contexts before settling names, paths or syntax.
- Keep the API model (RAML or OAS) maintained as the shared contract while the implementation evolves.
API-led connectivity: a methodical way to connect data to applications through reusable and purposeful APIs. System API: an API that connects directly to a core system and unlocks its data. Process API: an API that orchestrates System APIs and other Process APIs into reusable business logic. Experience API: an API that adapts Process API output for one consumer, such as a mobile app. Bounded context: the part of a domain model within which one API's responsibility and request-response model are defined (API-led advantages, API-led essentials, Common API mistakes).
Key facts
- Detail
- Three layers are a starting point; API-led is not strictly restricted to them.
- Detail
- A non-MuleSoft System layer can sit under a MuleSoft System API wrapper.
- Detail
- Lets policies such as throttling manage QoS to backend APIs.
- Detail
- A fit-for-use Process API can be consumed without an Experience layer.
- Detail
- A single System API can move files with no Process API.
- Detail
- File Transfer, Shared Database, Remote Procedure Invocation, Messaging.
- Detail
- Domain model and bounded contexts define responsibility and request-response model.
- Detail
- Model-first, then maintained during implementation.
- Detail
- Adapts Process API output for a specific UI or device.
- Which tools does the Common API mistakes article name for capturing a RAML or YAML model up front?
- When should an architect weigh deployment topology and expected acquisitions in a layering decision?
- Which test-time artefacts can an API model seed besides scaffolding and documentation?
- Which four integration styles does the Enterprise Integration Patterns page map to Mule objects?
- Why does API-led connectivity keep each API pertinent to its bounded context and loosely coupled?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the MuleSoft Platform Integration Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 40 lessons of the MuleSoft Platform Integration Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Practice exams purchase adds inline bank questions and topic practice (5 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Choose guide-only, practice-only, or save $4 with both