API Design

API Design: interfacce che reggono l'integrazione reale, non la demo

Un'API è un contratto: una volta che qualcuno la usa, cambiarla costa. Progettarla bene significa pensare fin dall'inizio a versioning, gestione degli errori, sicurezza e documentazione, non aggiungerli dopo quando i problemi sono già in produzione e i client a valle già rotti. In questa categoria raccolgo il metodo con cui si costruisce un'API destinata a essere integrata sul serio.

Il primo tema è il contratto e i suoi standard. Una buona API parla un linguaggio prevedibile: gestione strutturata degli errori secondo Problem Details, documentazione generata dal codice con OpenAPI così che non diverga mai dall'implementazione, versioning pensato per far evolvere l'interfaccia senza rompere chi la usa. Sono le fondamenta che distinguono un'integrazione che dura da una che genera ticket a ogni rilascio.

Il secondo tema è la tenuta sotto integrazione reale: rate limiting per difendersi dagli scraper senza penalizzare i client legittimi, API gateway per centralizzare autenticazione e routing, webhook con delivery garantita e retry, load test che mettono alla prova l'API prima del go-live. E il fronte nuovo, dove le API incontrano l'AI: output strutturato validato, content negotiation per servire gli agenti, governance dei costi e degli abusi quando dall'altra parte non c'è più un browser ma un modello.

Se stai progettando o consolidando delle API, vedi l'integrazione di sistemi e AI o scrivimi.

Un'API ben progettata la capisci senza leggere la documentazione. Quella mal progettata non la capisci nemmeno leggendola.