Apply API-led connectivity and layered API design
The exam tests whether you can place logic in the right API-led layer and defend the reuse economics. Questions often describe a new channel or a second consumer and ask where the change belongs.
Layer responsibilities
- Experience APIs: channel-specific composition and presentation-friendly payloads; thin, owned by the channel team.
- Process APIs: business orchestration across multiple systems; reusable across channels; own the business transaction.
- System APIs: access to a system of record; protocol translation, canonicalization, and insulation from schema change; no business process.
Rules
Dependencies point downward: experience calls process, process calls system. A channel should not own orchestration. Design contracts first and version them semantically. Reuse is a driver, not a slogan: a process API should exist because a capability is shared, not because three layers look tidy. System APIs should expose business entities, not raw tables.
Worked example
Web and mobile both need customer profile data from SAP and CRM. Put aggregation and business rules in a CustomerProfile process API; give web and mobile separate experience APIs that shape fields and errors for each channel. If mobile later needs a new field, only its experience API changes. Reasoning: the shared orchestration is reused, and channel variation is isolated.
Traps
Putting business logic in experience APIs; creating one process API per consumer; exposing database schemas through system APIs; making layers so coarse that teams cannot own them; assuming every integration needs exactly three layers; skipping contract versioning.