REST API, JSON e Ansible

Automazione di rete e API: il contesto CCNA

Nelle reti moderne la configurazione manuale via CLI non scala. L’automazione si appoggia a interfacce programmatiche (API) che permettono a script e controller (come Cisco DNA Center) di leggere e modificare lo stato dei device in modo strutturato. Per il CCNA devi saper riconoscere come funziona una REST API, leggere il JSON e distinguere i tool di configuration management.

Le REST API: caratteristiche fondamentali

Una REST API (Representational State Transfer) è un’interfaccia che opera tipicamente su HTTP/HTTPS (porte 80/443). È il modello dietro le northbound API di un controller SDN.

Tre proprietà chiave:

• Client-server: il client invia una richiesta HTTP a un URI (endpoint), il server risponde.
• Stateless: ogni richiesta è indipendente e autosufficiente. Il server non conserva lo stato della sessione tra una chiamata e l’altra; ogni richiesta deve contenere tutte le informazioni necessarie (es. token di autenticazione).
• Cacheable e a livelli.

CRUD mappato sui metodi HTTP

Le operazioni CRUD si mappano direttamente sui verbi HTTP:

Status code della risposta

Il server risponde con un codice numerico che ne indica l’esito:

• 2xx – successo: 200 OK, 201 Created.
• 3xx – redirezione.
• 4xx – errore del client: 401 Unauthorized (autenticazione mancante/errata), 403 Forbidden, 404 Not Found.
• 5xx – errore del server: 500 Internal Server Error.

Ricorda: 4xx = colpa del client, 5xx = colpa del server.

Interpretare il JSON

I dati scambiati sono tipicamente in JSON (o XML). Devi saperne riconoscere la struttura:

• Oggetto → racchiuso in parentesi graffe { }, contiene coppie key-value.
• Coppia key-value → "chiave": valore, separate da virgola.
• Array → racchiuso in parentesi quadre [ ], lista ordinata di elementi.
• I valori possono essere stringhe (tra virgolette), numeri, booleani (true/false), null, oggetti o array annidati.

{
  "interface": {
    "name": "GigabitEthernet0/1",
    "enabled": true,
    "ipv4": ["10.0.0.1", "10.0.0.2"]
  }
}

Qui interface è un oggetto; ipv4 è un array di due stringhe; enabled è un booleano.

RESTCONF e NETCONF

Sono i due protocolli standard per configurare i device tramite modelli dati YANG:

• NETCONF: opera su SSH (porta 830), usa XML, prevede il concetto di datastore (running, candidate, startup).
• RESTCONF: è un’interfaccia REST su HTTPS che espone i dati YANG, supporta JSON o XML e usa i metodi HTTP (GET/POST/PUT/DELETE). Più semplice e “web-friendly” di NETCONF.

Tool di configuration management

Servono a portare i device verso uno stato desiderato in modo ripetibile. Il confronto centrale è agent-based vs agentless e push vs pull.

Ansible è il più rilevante per il CCNA:

• Agentless: non richiede software installato sui device gestiti; usa SSH (o API) già presente. Solo il control node ha Ansible.
• Push model: il control node spinge le configurazioni verso i device.
• I playbook sono file YAML (indentazione significativa, niente tab); descrivono task idempotenti. L’inventory elenca gli host gestiti.

Puppet e Chef sono invece agent-based con modello pull (l’agente sul device contatta periodicamente il master). Terraform è orientato al provisioning dell’infrastruttura più che alla configurazione continua.

Trappole tipiche d’esame

• Scenario: “Quale metodo HTTP recupera dati senza modificarli?” → GET (Read). Attenzione a non confonderlo con POST (Create).
• Scenario: “Un client riceve 401: di chi è il problema?” → del client (autenticazione mancante/errata). Tutti i 4xx sono errori client, i 5xx server.
• Scenario: “Il carattere [ ] in un payload JSON indica…” → un array (lista), mentre { } indica un oggetto con coppie key-value. Domanda ricorrente di riconoscimento struttura.
• Scenario: “Quale tool NON richiede agent sui dispositivi gestiti?” → Ansible (agentless, SSH, push). Puppet e Chef sono agent-based/pull.
• Scenario: “Formato dei playbook Ansible?” → YAML (non JSON, non Ruby). Ruby è Puppet/Chef; HCL è Terraform.