Concurrence

Ne jamais écraser une modification faite entre-temps, avec ETag et If-Match.

Deux scripts, ou un script et une personne dans l’espace client, peuvent modifier la même ressource au même moment. L’API vous donne deux garanties.

Ne pas écraser une modification : ETag et If-Match

Les ressources modifiables (pare-feu, règles…) renvoient un en-tête ETag, leur version. Renvoyez-le dans If-Match avec votre modification : si la ressource a changé depuis votre lecture, l’API refuse avec 412 precondition_failed au lieu d’écraser.

# 1. Lire et noter l'ETag
curl -si https://api.corcelink.fr/v1/compute/vps/vps-7c2e4a91/firewall -H "Authorization: Bearer $CORCELINK_API_KEY" | grep -i etag
# etag: "a41f0c9e2b7d5c18"

# 2. Modifier en exigeant cette version
curl -X PATCH https://api.corcelink.fr/v1/compute/vps/vps-7c2e4a91/firewall \
  -H "Authorization: Bearer $CORCELINK_API_KEY" -H 'If-Match: "a41f0c9e2b7d5c18"' \
  -H "Content-Type: application/json" -d '{"inbound_policy":"drop"}'

Sur un 412, relisez la ressource, appliquez de nouveau votre changement, puis renvoyez avec le nouvel ETag. Sans If-Match, la modification s’applique sur l’état du moment.

Lectures conditionnelles

Envoyez l’ETag reçu dans If-None-Match : si rien n’a changé, l’API répond 304 Not Modified sans corps. Pratique pour une supervision qui interroge souvent.

Une modification à la fois par ressource

Les écritures sur un même VPS passent une par une : deux scripts ne peuvent pas mêler leurs étapes. Si une autre modification de ce VPS est en cours depuis plus de 5 secondes, l’API répond 409 resource_busy avec Retry-After: 1. Les lectures ne sont jamais bloquées, et les autres VPS ne sont pas concernés.