# Variables

> Lire et écrire les réglages que le service lit à son démarrage.

```http
GET /api/resources/{id}/variables
```

```json
[
  {
    "envVariable": "MESSAGE",
    "name": "MESSAGE",
    "description": "",
    "value": "reseau par projet",
    "editable": true,
    "varType": "STRING",
    "required": false,
    "allowedValues": [],
    "minValue": null,
    "maxValue": null
  }
]
```

`editable` à `false` marque un réglage fixé à la commande : il se lit, il ne s'écrit pas.
`varType` vaut `STRING`, `INT`, `FLOAT`, `BOOL` ou `ENUM` ; quand `allowedValues` n'est
pas vide, la valeur doit en faire partie.

## Écrire

```http
PUT /api/resources/{id}/variables
```

```json
{ "values": { "MESSAGE": "bonjour", "MAX_PLAYERS": "32" } }
```

Les valeurs sont **toujours des chaînes**, même pour un entier ou un booléen. Tu n'es pas
obligé de tout renvoyer : seules les clés présentes sont modifiées. La réponse est la
liste complète relue.

Une valeur refusée par les règles du réglage rend un `400` qui nomme le coupable :

```json
{
  "statusCode": 400,
  "message": "Réglage « MAX_PLAYERS » refusé : attendu un entier."
}
```

Un réglage non modifiable rend lui aussi un `400`.

## Quand ça s'applique

Au prochain démarrage du service. Le nœud est prévenu tout de suite, mais un processus
déjà lancé ne relit pas son environnement — [redémarre-le](/api/cycle-de-vie) pour que la
nouvelle valeur compte.

## Les références entre services

Une valeur peut pointer vers un voisin du même projet :

```json
{ "values": { "DATABASE_URL": "${crm-db.URL}" } }
```

`${alias.HOST}`, `${alias.PORT}` et `${alias.URL}` sont résolus au démarrage, à partir de
l'alias du service visé. C'est ce qui permet de brancher une application sur sa base sans
écrire d'adresse en dur, et sans rien ouvrir sur Internet.