Prima il contratto, poi il codice.
Riprendi il progetto “API persone” del manuale. Prima di aggiungere nuove route, scrivi cosa si aspetta il client e cosa promette il server. Questa descrizione è il contratto della tua API.
1. Descrivi una risorsa
Per ogni persona, elenca i campi, il loro significato e le regole. Distingui quelli obbligatori da quelli facoltativi. Chi decide l’ID? Cosa significa un nome vuoto? Due persone possono avere lo stesso nome? Scegli una regola esplicita e applicala in tutte le route.
2. Costruisci una tabella
| Richiesta | Caso riuscito | Caso da verificare |
|---|---|---|
| GET /persone | Elenco JSON, anche vuoto | Filtri non riconosciuti |
| GET /persone/:id | Persona corrispondente | ID valido ma inesistente |
| POST /persone | Nuova persona con ID | Body assente o nome vuoto |
| PUT /persone/:id | Risorsa sostituita | Campi richiesti mancanti |
| DELETE /persone/:id | Eliminazione senza body | Seconda eliminazione dello stesso ID |
Completa la tabella con gli status code previsti dal laboratorio. Un caso non riuscito deve produrre una risposta comprensibile, coerente e controllabile dal client.
3. Verifica sequenze, non solo richieste isolate
- Crea una persona e conserva l’ID restituito.
- Leggila con una GET di dettaglio.
- Aggiornala e rileggila: i nuovi valori sono quelli attesi?
- Eliminala e ripeti la GET: la risorsa non deve essere trovata.
- Ripeti i casi con dati non validi. Il server continua a rispondere?
4. Tieni traccia di atteso e osservato
Per ogni prova annota metodo, URL, body, status atteso, status ricevuto e risposta. Cambia un solo elemento alla volta: se modifichi insieme route, dati e filtro, sarà più difficile capire la causa di un errore.
Prova tu
Scrivi una checklist di dieci prove per l’API persone: cinque casi validi e cinque casi limite. Eseguila sul progetto del manuale, correggi gli errori e ripetila. La verifica è conclusa quando sai spiegare ogni risultato.