API-First Design Thinking for BAs (Course #api-design-thinking)

Programme every line is something you do

4 modules · 12 topics · in course-flow order

1. Module 1

   From User Stories to Contracts

   Objective. Derive API candidates from the Norvia domain and frame each as a product with named consumers and measurable service targets.

   • Extract API candidates from journey maps and domain events, sized by expected load, e.g. payment initiation at 50 TPS peak
   • Frame APIs as products: consumers, SLA tiers and deprecation intent written on an API canvas before any OAS 3.x modeling
   • Write requirements developers can scaffold from: resources, query parameters, error payloads — ready for RAML 1.0 or OAS 3.x
2. Module 2

   Read a Spec Like an Architect

   Objective. Review a RAML 1.0 or OAS 3.x specification before sprint planning and reject blocking ambiguities with documented findings.

   • Navigate an OAS document with intent: paths, components/schemas, responses, securitySchemes — and what each section commits to
   • Contrast RAML 1.0 with OAS 2.0 vs 3.x: links, callbacks, webhook support, $ref semantics — and what each format cannot express
   • Run a 10-point spec review checklist — naming, pagination, error model (RFC 7807), examples — and log defects before sprint start
3. Module 3

   Acceptance Criteria That Gate

   Objective. Specify testable acceptance criteria per endpoint and prove them against the mocking service before implementation starts.

   • Define Given/When/Then criteria per endpoint, adding idempotency-key rules on POST /payments to make client retries safe
   • Specify status-code classes, payload schemas and error contracts per failure mode, e.g. 429 with Retry-After on throttling
   • Exercise the Design Center mocking service against each criterion and raise gaps as defects before code exists
4. Module 4

   Reuse Before You Build

   Objective. Audit Anypoint Exchange ahead of each requirement and price the reuse gain so duplicate builds never reach the backlog.

   • Search Anypoint Exchange by capability, tag and owner; shortlist assets on latest version, documentation depth and usage
   • Challenge a duplicate build with figures, e.g. reusing the Customer API saves ≈ 40 dev-days and one lifetime maintenance burden
   • Convert findings into backlog decisions — adopt, extend or wrap an existing API — with the version impact stated (minor vs major)

References & Official Documentation every claim above has a source

Module 1

• APIkit OverviewMuleSoft Docs

Module 2

• OpenAPI Specification v3.1.2Specification
• RFC 9457 — Problem Details for HTTP APIsSpecification
• Anypoint API Governance OverviewMuleSoft Docs

Module 3

• Add Behavioral Headers to Simulated API CallsMuleSoft Docs
• Simulate API Calls with the Mocking ServiceMuleSoft Docs

Module 4

• Asset VersionsMuleSoft Docs
• Searching for AssetsMuleSoft Docs

More in Business & Leadership