# Référence de la configuration

> Les deux schémas publiés de la configuration et des extensions du contrat, et ce que chaque clé y porte : type, défaut, version, rechargement.

Référence - Depuis la version 1.7.0 - Flexway v1.7.1 - https://flexway.io/docs/operations-configuration-reference/

> Guide d'exploitation : configurer, déployer et observer la passerelle. Ce que fait la fonctionnalité côté produit : [guide produit](https://flexway.io/docs/product-overview/) ; l'appeler : [guide développeur](https://flexway.io/docs/developer-overview/).

Connaître, pour chaque mot-clé, sa syntaxe, ses options et ses valeurs admises - avant
de l'écrire.

## Les schémas publiés

La référence est le **schéma publié**, écrit depuis le modèle de la passerelle à chaque version - jamais
à la main, donc jamais en retard sur le code :

| Fichier | Ce qu'il décrit | Adresse |
| --- | --- | --- |
| `flexway.schema.json` | Tout `flexway.yaml`, et la `config` de chaque type de politique (sous `$defs`, `policy.<type>`) | `https://flexway.io/schema/v1/flexway.schema.json` |
| `architecture.schema.json` (depuis `1.7.0`) | Le modèle d'architecture `flexway.architecture.v1` que sert l'écran Architecture de la console : routes, stations, correspondances, refus, ce qui n'est pas dessiné | `https://flexway.io/schema/v1/architecture.schema.json` |
| `contract-extensions.schema.json` | Chaque extension `x-flexway-*` du contrat (OpenAPI, AsyncAPI, carte A2A) et l'option gRPC `flexway.v1.operation` | `https://flexway.io/schema/v1/contract-extensions.schema.json` |
| `policy-fragment.schema.json` | Un fichier de fragment de politique (`kind: PolicyFragment`, [fragments partagés](https://flexway.io/docs/operations-policy-fragments/)) - depuis `1.7.0` | `https://flexway.io/schema/v1/policy-fragment.schema.json` |

Chaque fichier est joint aux releases à partir de celle qui le livre, et écrit par `flexway schema` depuis l'image de la
version ([valider dans son éditeur](https://flexway.io/docs/operations-editor-validation/)).

## Ce que chaque clé porte

| Champ du schéma | Sens |
| --- | --- |
| `type`, `enum`, `pattern`, `minimum`, `maximum` | Syntaxe et valeurs admises ; une durée s'écrit `3s`, `250ms`, `1m30s`, une taille `1MiB`, `512KiB` |
| `default` | La valeur en vigueur quand la clé est absente |
| `required` | Les clés à écrire dès que le bloc qui les contient est écrit |
| `additionalProperties: false` | Le décodage est strict : une clé inconnue est refusée |
| `description` (anglais), `x-flexway-description` (`fr`, `en`) | Ce que fait la clé, ses options, ses refus |
| `x-flexway-since` | La version qui a apporté la clé |
| `x-flexway-reloadable` | `false` : un changement de cette clé exige un redémarrage, le rechargement est refusé en bloc |
| `x-flexway-reference` | Un secret : une référence `${VAR}` ou `file:/chemin`, jamais la valeur |
| `x-flexway-places` (extensions) | Où l'extension est lue : `openapi.info`, `openapi.operation`, `asyncapi.operation`, `asyncapi.parameter`, `asyncapi.message`, `a2a.card`, `grpc.method` |

## Exemple

`flexway schema --out .` puis chercher une clé, par exemple `server.timeouts.connect` :
`type: string`, `default: "5s"`, `x-flexway-since: "0.2.0"`, `x-flexway-reloadable: true` et sa
description.

> [!NOTE]
> Le schéma décrit chaque clé seule ; les règles qui croisent la configuration et les contrats restent
> celles de `flexway validate`.