Développement Assurance qualité 1 day

Design d'API spec-first avec l'OAS (Course #oas-design)

For développeurs, BAs, architectes.

S'inscrire à ce cours Toutes les formations
Réf#oas-design
Durée1 jour
Formats4 modalités
Certif—
PrérequisAucun

À la fin, vous saurez

À l'issue de cette formation, vous serez capable de concevoir, mocker, générer et gouverner des spécifications OAS 3.x afin de ramener l'intégration partenaire à quelques jours, contrats testés en CI.

Cas fil rouge

Vela Mobility agrège des opérateurs de stationnement et de transport derrière des API partenaires documentées en PDF et wikis ; chaque intégration démarre par un fil d'e-mails et se termine en rupture de contrat. Un portail développeur en self-service fait de l'OAS 3.x la source unique de vérité — mockée avant tout code, gouvernée dans Exchange. Vous repensez leur API de réservation phare en spec-first.

Programme chaque ligne est quelque chose que vous faites

6 modules · 11 sujets · dans l'ordre du cours

  1. Module 1

    Anatomie d'un document OAS

    Objectif. Structurer un document OAS 3.x complet pour l'API de réservation : paths, components, schemas, securitySchemes.

    • Structurer un document OpenAPI : écarts 2.0 vs 3.x, servers, paths, components/schemas, securitySchemes
  2. Module 2

    RAML 1.0 rencontre OAS 3.x

    Objectif. Convertir l'héritage RAML 1.0 de Vela vers OAS 3.x sans perdre exemples, traits ni security schemes.

    • Convertir entre RAML 1.0 et OAS 3.x avec l'outillage, puis réparer ce que l'automatisation abandonne
    • Peser les trade-offs : resourceTypes/traits vs components, includes vs $ref, écosystèmes d'outillage
    • Trancher par contexte : API partenaires greenfield, API internes, specs destinées aux policies d'API Manager
  3. Module 3

    Mocker d'abord, coder ensuite

    Objectif. Itérer le design dans API Designer et confronter le mocking service aux retours réels des consommateurs.

    • Concevoir en itérations dans Design Center/API Designer : validation en direct, doc inline, extraits de spec
    • Valider tôt avec API Console et le mocking service : transformer les exemples en attentes exécutables
  4. Module 4

    De la spec au squelette exécutable

    Objectif. Générer des flows APIkit exécutables depuis la spec OAS dans Studio/ACB et bloquer les merges sans tests de contrat.

    • Générer les flows APIkit depuis l'OAS dans Studio ou Anypoint Code Builder, opération par opération
    • Faire respecter le contrat en CI : statuts, schemas et exemples vérifiés contre la spec
  5. Module 5

    Des style guides qui font respecter

    Objectif. Publier la spec versionnée sur Exchange et faire appliquer un style guide qui rejette les designs non conformes.

    • Publier les specs sur Exchange avec doc, exemples, versions et états de cycle de vie
    • Appliquer checklists et style guides : nommage, pagination, modèles d'erreur RFC 7807, règles de versionnage
  6. Module 6

    Lab : l'API de réservation de bout en bout

    Objectif. Emmener l'API de réservation sur la boucle complète : design OAS 3.0, mock, scaffolding, publication sur Exchange.

    • Concevoir une API OAS 3.0, la mocker via le mocking service, générer les flows et la publier sur Exchange

Références & documentation officielle chaque affirmation ci-dessus a une source

Module 1

Module 2

Module 3

Module 4

Module 5

Dans la filière Développement

#dev-fundamentals · Développement Anypoint Platform : les fondamentaux#code-builder · Anypoint Code Builder : l'essentiel#advanced-mule4 · Développement Mule 4 avancé#eda-mq · Architecture événementielle avec Anypoint MQ#b2b-edi · Intégration B2B avec Anypoint Partner Manager & X12 EDI#api-styles · Styles d'API modernes#ai-capabilities · Capacités IA de MuleSoft#agent-fabric · Agent Fabric et gouvernance des réseaux d'agents#dataweave · DataWeave en profondeur

Une formation pour votre équipe ?

Chaque session est adaptée à vos cas d'usage, vos données et votre planning.

Demander un devis