Aller au contenu principal
FONCTIONNALITÉ 05 / 11

Plusieurs specs OpenAPI, un seul portail.

Déclarez une liste de specs et une seule installation les documente toutes : un sélecteur dans l’en-tête, un document chargé à la fois, et tout ce que le lecteur accumule — environnements, historique, jetons — cloisonné par spec.

demo.apiglow.dev/#/overview · payments + accounts
Le sélecteur d’API du bandeau ouvert sur deux specs — Petstore (demo) et Library API — avec la spec active cochée. Le sélecteur d’API du bandeau ouvert sur deux specs — Petstore (demo) et Library API — avec la spec active cochée.

CAPTURE RÉELLE, AFFICHÉE À 1:1

Un sélecteur, plusieurs API.

Chaque entrée a un id stable, un title pour le sélecteur, et son schéma par URL ou en ligne. Seule la spec active est téléchargée — une installation à douze API n’en coûte qu’une au lecteur. Chaque spec a ses propres routes (#/s/{id}/…), donc les liens profonds tombent sur la bonne API, et default choisit celle affichée à l’arrivée.
Le sélecteur de spec ouvert sur deux entrées : Petstore (demo), coché, et Library API. Le sélecteur de spec ouvert sur deux entrées : Petstore (demo), coché, et Library API.
[01]LE SÉLECTEUR DE SPEC, DANS L’EN-TÊTE
Deux API, une installation
{
  "openapi": {
    "specs": [
      {
        "id": "payments",
        "title": "Payments API",
        "url": "https://example.com/payments.json"
      },
      {
        "id": "accounts",
        "title": "Accounts API",
        "url": "https://example.com/accounts.yaml",
        "features": { "scenarios": false }
      }
    ],
    "default": "payments"
  }
}

L’isolation est totale.

Environnements, mémoire d’en-têtes, historique, jetons OAuth, scénarios, recherche — tout est cloisonné par spec. Un jeton de l’API Payments ne peut pas fuiter dans une requête vers Accounts ; changer de spec, c’est changer de monde. Une conséquence à connaître : l’id sert aussi de préfixe de stockage, le renommer revient à remettre à zéro les données locales de cette spec.

L’héritage, avec des règles dites.

La config racine sert de socle et presque chaque clé se redéclare sur une entrée — branding, thème, réglages de la console, interrupteurs de fonctionnalités, environnements. Les règles de fusion sont peu nombreuses et énoncées : les objets de réglages fusionnent clé par clé, la spec gagne ; les listes d’entités nommées fusionnent par identifiant ; hide et les overlays s’accumulent, racine d’abord. Tout ce qu’une entrée déclare sans que ça puisse s’appliquer est signalé nommément en console, jamais avalé.

Trois clés ne voyagent pas.

history reste à la racine — la rétention est un plafond de stockage navigateur, appliqué à toutes les specs à la fois. theme.custom reste à la racine — les thèmes sont du chrome global, injecté une fois au démarrage. Et scenarios fait le chemin inverse : déclarés uniquement sur les entrées, parce qu’un scénario référence les opérations d’une spec précise. Chaque cas est signalé en console quand une config se trompe.