Anypoint fait tourner vos APIs, Postman les met entre toutes les mains

J’ai travaillé chez MuleSoft avant de rejoindre Postman, et j’ai utilisé les deux produits pendant tout ce temps. Postman a toujours été la solution de référence pour tester une API, y compris pour ceux qui les construisent sur Anypoint.

La question revient dans presque toutes mes conversations avec une équipe MuleSoft : on paie déjà Anypoint Platform, pourquoi ajouter un deuxième outil d’API ?

C’est une question légitime. La réponse courte, c’est que Postman n’est pas un second Anypoint, et pas non plus un client avec des tests greffés dessus. C’est une plateforme pour le cycle de vie des APIs : design de spec avec un vrai contrôle des changements, mocking, tests de contrat et de charge, gouvernance as code, catalogage, distribution. Elle couvre des étapes pour lesquelles Anypoint n’a pas été conçu, et s’adresse à des rôles pour lesquels il n’a pas été pensé.

MuleSoft implémente des APIs en low-code et les sécurise derrière l’Omni Gateway. Ce n’est pas le sujet de ce post, et ce n’est pas ce que Postman remplace.

Deux choses changent quand on fait tourner les deux côte à côte. Qui peut interagir avec ces APIs, et à quelle vitesse vous pouvez les modifier sans baisser vos standards.

Qui peut atteindre vos APIs aujourd’hui

Anypoint est fait pour les gens qui implémentent les intégrations, et ce sont ces gens-là qui s’y connectent. Une QA ou un product manager n’a aucune raison d’ouvrir Design Center ou API Manager : rien là-dedans ne s’adresse à eux.

Tous les autres touchent quand même ces APIs. Les équipes front et mobile. La QA. Les product managers qui doivent savoir si un endpoint est prêt. Les data engineers qui appellent un service depuis un notebook. Le partenaire externe qui s’intègre à vous. Au total, ils sont bien plus nombreux que l’équipe Mule.

Le travail passe donc par mail et par Slack, et le vrai coût, c’est le va-et-vient. Il n’existe aucun endroit unique qui soit à jour. Une API change, et quelqu’un doit reconstruire la collection à la main pour qu’elle corresponde. Ce qui circule est une copie : l’équipe front finit par tester sur une collection exportée trois semaines plus tôt, remonte un bug corrigé depuis quinze jours, et l’équipe d’intégration passe un après-midi à prouver que l’endpoint fonctionnait parfaitement. Multipliez par chaque API et chaque équipe consommatrice : la dette technique s’accumule à chaque changement de contrat.

Salesforce possède MuleSoft et a quand même choisi le Public API Network de Postman pour sa distribution externe : son workspace est parmi les plus actifs du réseau, avec plus de 200 000 forks de collections, et il héberge la collection des APIs Anypoint Platform de MuleSoft. Le blog de MuleSoft a par ailleurs décrit Postman comme le standard pour tout développeur qui travaille avec des APIs. L’entreprise qui possède Anypoint a tiré la même conclusion pour la partie consommation du cycle de vie.

Qui fait quoi à chaque étape

Cliquez sur une étape pour voir le détail :

MuleSoft tient le cœur de la chaîne : l’implémentation et le runtime. Postman tient les deux bouts, et fait le lien qui permet de faire évoluer ce cœur sans casser ce qui est branché dessus.

La collaboration, concrètement

On importe dans Postman les définitions des APIs déjà déployées, depuis Anypoint Exchange, et on les garde synchronisées. Exchange reste la source de vérité du runtime. Mais une QA, une product manager ou un partenaire peut désormais trouver cette API, la lire, l’essayer, la forker dans son propre workspace et écrire un test dessus. Mêmes APIs, même runtime, utilisables par le reste de l’entreprise.

Trois choses comptent en pratique :

Les Partner Workspaces. Des espaces isolés où des développeurs externes travaillent aux côtés de votre équipe sur des collections partagées, sans distribuer d’accès plateforme ni faire circuler un export de collection par mail. Exchange et Experience Hub donnent aux consommateurs un portail à lire ; ici, on co-développe.

Un catalogue plutôt que trois. Exchange référence ce qui est passé par Mule. Vos développeurs consomment aussi des APIs internes jamais « mule-ifiées », plus Stripe, plus ce que l’équipe data a monté dans son coin. L’API Catalog de Postman recense les APIs quelle que soit leur source, et affiche la version de la spec, le score de gouvernance, l’historique CI, les résultats de tests et un propriétaire par API. Exchange affiche le statut de la spec. Ces deux choses répondent à des questions différentes, et une seule vous dit si on peut se reposer sur un service aujourd’hui.

Une porte d’entrée unique. Publier l’API sur le Private API Network donne à tout le monde une seule barre de recherche, et l’entrée qu’on y trouve reste liée à la spec plutôt qu’à l’export de quelqu’un. Les équipes formulent ce besoin avant qu’on le suggère, parce qu’Anypoint n’a jamais eu vocation à servir un product manager ou une QA, alors que Postman, oui.

Concevoir le contrat avec un vrai contrôle des changements

Design Center écrit très bien du RAML et de l’OpenAPI. Trois caractéristiques en font un mauvais espace de conception à plusieurs, et elles sont structurelles, pas cosmétiques :

• Pas d’édition concurrente. Une personne tient la spec et tous les autres attendent.
• Commit automatique à chaque changement. On finit avec des milliers de commits sans intention. L’historique existe mais on n’en lit rien, donc le versioning cesse d’être utile et devient du bruit.
• Pas de quality gate avant Exchange. La gouvernance existe, mais n’importe quoi peut être publié. Un écart aux règles de design se voit plutôt au moment des tests, après le déploiement de l’API, et seulement si ce contrôle a été mis en place.

Les Specs de Postman sont Git-natives, ce qui règle les trois : on branche une spec, on ouvre une pull request, on fait relire, on verrouille le merge par RBAC. Les règles de gouvernance tournent directement dans l’éditeur pendant qu’on tape, puis à nouveau en CI avant le merge. Anypoint n’a pas d’équivalent pour ce workflow de revue et d’approbation d’un changement de contrat.

Il y a une deuxième raison d’écrire dans Spec Hub, et c’est celle qui compte le plus au quotidien. La spec et la collection sont le même artefact : générer la collection depuis la spec, et la régénérer quand la spec change, c’est un clic. C’est le va-et-vient du début de ce post qui disparaît : personne n’exporte de collection, personne ne la fait circuler, et personne ne teste sur une copie qui n’est plus à jour depuis trois semaines.

Le flux que je mettrais en place ressemble à ceci. La spec est écrite dans Spec Hub, pas éditée à la main dans un dépôt :

      ┌──────────────────────────────────────────────────┐
      │ Spec Hub                                         │
      │ rédaction, gouvernance dans l'éditeur            │
      └────────────────────────┬─────────────────────────┘
                               │  local mode
                               ▼
      ┌──────────────────────────────────────────────────┐
      │ Branche Git + pull request                       │
      │ revue, RBAC sur le merge                         │
      └────────────────────────┬─────────────────────────┘
                               │  CI
                               ▼
      ┌──────────────────────────────────────────────────┐
      │ postman spec lint                                │
      │ quality gate, bloque le merge                    │
      └────────────────────────┬─────────────────────────┘
                               │  au merge
               ┌───────────────┴───────────────┐
               ▼                               ▼
  ┌──────────────────────────┐    ┌──────────────────────────┐
  │ Postman cloud            │    │ Anypoint Exchange        │
  │ collection, mock, tests, │    │ dépendance APIkit,       │
  │ docs, API Catalog        │    │ source du runtime        │
  └──────────────────────────┘    └──────────────────────────┘

Le local mode garde la spec sous forme de vrais fichiers dans votre dépôt : Git gère le transport et la revue, tandis que Spec Hub reste l’endroit où humains et agents l’éditent réellement. Le merge alimente les deux plateformes, puisque vous avez bien besoin de l’API dans Exchange pour qu’APIkit et Studio la résolvent.

Plus rapide et plus sûr à la fois

En principe, vitesse et sûreté s’opposent. Le comité de revue qui attrape les breaking changes est aussi ce qui ralentit chaque livraison. Ce compromis existe surtout parce que le quality gate est une personne qui lit un diff.

Une fois les quality gates codifiés, le rapport change :

Branché sur un pipeline Anypoint, le déploiement lui-même ne change pas :

- name: Gate 1 - gouvernance sur la spec
  run: |
    postman login --with-api-key "$POSTMAN_API_KEY"
    postman spec lint ./specs/customer-360.yaml \
      --fail-severity ERROR \
      --report-events

- name: Synchronise le contrat vers Postman et vers Exchange
  run: |
    postman workspace push --yes
    mvn deploy -Dexchange

- name: Deploy to CloudHub 2.0
  run: mvn deploy -DmuleDeploy -Denv=uat

- name: Gate 3 - tests de contrat sur UAT
  run: |
    postman collection run "$COLLECTION_UID" \
      --environment "$UAT_ENVIRONMENT_UID" \
      --bail \
      --reporters cli,junit \
      --reporter-junit-export results.xml

- name: Promote to production
  if: success()
  run: mvn deploy -DmuleDeploy -Denv=prod

--report-events est un petit flag qui change la perception en interne : les résultats du lint remontent dans Postman et apparaissent par API dans l’API Catalog, sous les runs de pipeline CI. La gouvernance devient un chiffre attaché à chaque service, visible par des gens qui n’ont pas accès à la CI, au lieu d’un rapport que quelqu’un produit une fois par trimestre.

--bail compte aussi, pour qu’un contrat cassé arrête la promotion au lieu de produire un rapport rouge que personne n’ouvre.

Pourquoi les tests d’API n’ont pas leur place dans le projet Mule

MUnit couvre l’intérieur d’une application Mule : les transformations DataWeave, les branches d’erreur, le comportement des connecteurs avec mock-when. C’est à ça qu’il sert, et c’est le bon endroit pour ce type de vérification.

C’est en revanche un mauvais endroit pour vos tests d’API, et les raisons tiennent toutes à la gestion plutôt qu’à ce qu’il sait vérifier. Il s’écrit à la main, dans l’IDE, par quelqu’un qui écrit du DataWeave, ce qui exclut vos QA. Il vit dans le projet de l’API, donc il n’existe aucune vue de la couverture sur un parc. Il s’exécute sur une implémentation qui doit exister d’abord, donc rien ne peut être testé avant que le flow soit construit. Et modifier un test veut dire modifier l’application et la redéployer : le cycle de vie des tests est soudé à celui du déploiement, soit l’inverse de ce qu’on attend d’un test.

Il ne suit pas non plus le contrat. Publier un changement de spec vers Exchange, c’est un clic, et le mock se régénère tout seul, mais la suite de tests ne suit pas. Quelqu’un doit incrémenter la version de la spec dans l’IDE puis réécrire les tests à la main, donc ils s’éloignent de la spec par défaut.

Les tests générés depuis la spec dans Postman inversent tout ça. Ils vivent à côté du contrat et se régénèrent avec lui. Ils tournent depuis un poste, depuis la CI, ou à intervalle fixe en monitor, sans aucun redéploiement. Et n’importe quel rôle peut les lire et les étendre, ce qui fait de la couverture le travail de quelqu’un plutôt que de personne.

C’est l’Agent Mode qui rend la chose praticable sur un parc entier et pas sur une seule API. Pointez-le sur une spec : il écrit les tests fonctionnels et de contrat de chaque opération, y compris les réponses d’erreur que tout le monde oublie. Pointez-le sur un endpoint dont le contrat vient de changer : il met à jour les assertions concernées, au lieu de vous laisser fouiller la collection pour les retrouver. Demandez-lui où la couverture est faible, il vous le dira, ce qu’aucune suite MUnit éparpillée dans quarante projets Mule ne sait faire.

Deux manques liés :

• Pas de test de contrat champ par champ. APIkit valide le trafic entrant contre la spec au runtime, et on peut générer une suite MUnit depuis une spec, mais rien ne compare une réponse réelle à l’OpenAPI publié champ par champ et type par type.
• Pas de test de charge natif. La réponse est JMeter, Gatling ou BlazeMeter : un outil à part, un environnement de rédaction à part, une chose de plus à maintenir.

Voici les assertions qui tournent dans le playground plus bas, sur la réponse de l’Experience API :

const body = pm.response.json();

pm.test("Status code is 200", () => pm.response.to.have.status(200));

pm.test("customerId matches the path parameter", () => {
  pm.expect(body.customerId).to.eql(pm.variables.get("customerId"));
});

// SAP nomme ses champs en capitales (KUNNR, NAME1, KLIMK). Les System APIs les
// exposent tels quels ; l'Experience API est censée les traduire. Donc toute clé
// en capitales dans ce payload signifie qu'il en est passé une, peu importe laquelle.
pm.test("No raw ERP field name leaks through", () => {
  const shouty = JSON.stringify(body).match(/"[A-Z][A-Z0-9_]{2,}":/g) || [];
  pm.expect(shouty, `leaked: ${shouty.join(", ")}`).to.be.empty;
});

pm.test("Available credit never exceeds the limit", () => {
  pm.expect(body.credit.available).to.be.at.most(body.credit.limit);
});

La troisième assertion mérite une explication, parce que c’est celle qui est propre à l’API-led. SAP nomme ses champs en capitales : KUNNR pour le numéro de client, KLIMK pour la limite de crédit. La System API les expose exactement comme ça, et c’est correct à ce niveau. L’Experience API, elle, est censée les traduire en vocabulaire métier : customerId, credit.limit. Le test ne cherche donc pas un champ en particulier. Il balaie tout le payload à la recherche d’une clé écrite en capitales et échoue s’il en trouve une, quel que soit son nom.

Ça attrape une régression qu’aucune suite MUnit ne verra. Quelqu’un ajoute un champ au mapping DataWeave, oublie de le renommer, et KLIMK se retrouve dans le payload public. Le flow fonctionne, la transformation est juste, et MUnit reste vert, parce que personne n’a jamais écrit d’assertion disant qu’aucun champ ne doit être nommé en capitales. Le contrat est cassé quand même : les consommateurs lisent maintenant du vocabulaire SAP qui devait rester derrière la couche System API, et le leur retirer plus tard sera un breaking change.

Planifier la même collection en monitor continue de vérifier tout ça en production ensuite. Un seul artefact du design jusqu’à la prod, rien de réécrit en chemin, et rien à redéployer pour changer un test.

Mocking : un contrat appelable avant qu’il existe

Le mocking service d’Anypoint fait quelque chose de comparable depuis une spec, avec une réserve : il vit dans le projet Design Center, et l’appelant a besoin d’un compte plateforme. Ce n’est pas une URL qu’on donne à un partenaire.

Ci-dessous, un distributeur fictif qui applique l’API-led connectivity : une System API sur le customer master SAP, une System API sur Salesforce, et une Experience API qui compose les deux en une ressource customer 360. Rien n’est déployé et il n’y a aucun runtime Mule derrière. C’est un mock server Postman généré depuis les examples de la collection, et les requêtes sont de vrais appels HTTP depuis votre navigateur.

Choisissez-en une, envoyez-la, et ouvrez l’onglet Tests.

Aucune réponse. Cliquez sur Envoyer.

Les deux cas d’erreur utilisent un en-tête propre à Postman, x-mock-response-code, qui indique au mock quel example renvoyer :

curl -s https://162287a0-ded5-4ae6-bc37-466a1de86ba8.mock.pstmn.io/customers/CUST-1042/profile \
  -H "x-mock-response-code: 401"

Le changement dans l’ordre des opérations est ce qui rend l’exercice utile. On écrit la spec, on génère le mock, on laisse l’équipe front et le partenaire s’intégrer dessus, et on implémente les flows après. On découvre qu’une réponse est mal fichue au moment où la corriger ne coûte encore rien, plutôt qu’une fois que trois équipes ont livré du code dessus. La QA peut écrire et jouer ses tests contre le mock avant que le flow Mule existe, donc QA et développement avancent en parallèle au lieu de se succéder.

Les agents changent ce qu’un contrat doit dire

Une personne relance un paiement échoué une fois, prudemment. Un agent le relance mille fois en une seconde. Une clé d’idempotence cesse d’être une bonne pratique et devient la différence entre une relance et une transaction dupliquée. Même chose pour les contrats d’erreur : un agent ne peut pas deviner ce que signifie un 4xx indocumenté, donc il improvisera avec aplomb, et de travers.

C’est la raison pratique d’écrire des règles de gouvernance. Une règle qui exige un en-tête Idempotency-Key sur chaque POST qui déplace de l’argent, c’est une façon de définir ce que « prêt pour l’IA » signifie dans une organisation donnée, puis de l’appliquer à chaque spec avant le merge plutôt que de compter sur la mémoire des gens.

La gouvernance de Postman tourne sur Spectral, un standard ouvert : les règles restent portables vers n’importe quel outil compatible, plutôt que liées au ruleset d’un seul éditeur.

Un dernier point à peser. Mule est un langage propriétaire, donc un modèle a bien moins de XML Mule et de DataWeave publics à apprendre que de Java ou de Python. L’assistance IA y est structurellement plus faible, et elle le reste à chaque génération de modèle. Ça oriente ce qui vaut la peine d’être construit en Mule et ce qui vaut la peine d’être construit dans un langage courant derrière la gateway.

Par où je commencerais

Pas par un déploiement de plateforme. Une seule API, sur le point d’être construite et réellement douloureuse, idéalement avec une équipe consommatrice impatiente en face.

1. Écrire la spec OpenAPI dans Spec Hub. Activer un petit ruleset de gouvernance, trois ou quatre règles auxquelles on croit vraiment. Pousser vers Git via le local mode et brancher postman spec lint sur la pull request.
2. Générer le mock et envoyer l’URL à l’équipe consommatrice le jour même, avant qu’un flow Mule existe.
3. Générer la collection depuis la spec. Ajouter des tests de contrat sur le happy path et sur chaque erreur documentée. Mettre le run de collection dans le pipeline comme quality gate, puis planifier la même collection en monitor de production.
4. Publier cette API sur le Private API Network, et inviter une QA et un product manager qui n’ont jamais eu de raison d’ouvrir Anypoint.

Quelques jours de travail sur une seule API, et vous avez autre chose qu’une slide à montrer : l’équipe consommatrice s’est branchée dessus avant que l’API n’existe, une régression de contrat a été bloquée en CI plutôt que remontée par un partenaire, et deux personnes qui n’avaient jamais ouvert Anypoint sont maintenant autonomes dessus.

Rien de tout ça ne demande de trancher sur une plateforme au préalable, et c’est justement l’intérêt. Une API, une spec, une collection, un pipeline, et vous saurez en quelques jours si la suite vaut la peine. Ce qu’il ne faut pas faire, c’est laisser les deux plateformes dans deux mondes séparés : c’est la version où la collection est exportée à la main et où tout le monde recommence à débattre de la copie qui fait foi.

Si vous tournez sous MuleSoft et que vous voulez voir où tout ça se placerait chez vous, ou si vous pensez que je me trompe quelque part, écrivez-moi sur LinkedIn. Je serai ravi d’échanger.