Guida Completa a OpenAPI e Swagger: Progettare, Documentare e Sviluppare API REST

Introduzione: Il Cuore della Comunicazione Web Moderna

Nel panorama della programmazione web contemporanea, le API (Application Programming Interfaces) sono diventate il collante fondamentale che permette a sistemi diversi di comunicare tra loro. Che si tratti di un'applicazione mobile che interagisce con un backend, di un frontend web che recupera dati, o di servizi che si scambiano informazioni in un'architettura a microservizi, le API REST sono onnipresenti. Tuttavia, la loro progettazione, documentazione e manutenzione possono diventare rapidamente complesse e disordinate senza gli strumenti e le metodologie adeguate. È qui che entrano in gioco OpenAPI Specification (OAS) e l'ecosistema Swagger, offrendo una soluzione standardizzata e potente per affrontare queste sfide.

OpenAPI non è solo un formato per descrivere le API; è un linguaggio comune che facilita la comprensione tra sviluppatori, tester e anche team di prodotto. Fornisce un modo per descrivere le capacità di un'API in un formato leggibile sia dagli esseri umani che dalle macchine, consentendo a tutti i partecipanti di comprendere e interagire con i servizi web in modo più efficiente. Swagger, d'altra parte, è un insieme di strumenti open source che implementano e sfruttano la specifica OpenAPI per rendere la vita degli sviluppatori più semplice, dalla scrittura della specifica alla generazione di documentazione interattiva e codice client/server.

Questo articolo si propone di guidarti attraverso i concetti fondamentali di OpenAPI e Swagger, spiegando non solo cosa sono, ma soprattutto perché sono indispensabili per qualsiasi sviluppatore web che lavori con le API. Esploreremo come utilizzare questi strumenti per progettare API robuste, generare documentazione accurata e automatizzare parti del processo di sviluppo, migliorando significativamente la qualità e la manutenibilità dei tuoi progetti.

Comprendere OpenAPI Specification (OAS)

L'OpenAPI Specification (OAS) è una specifica standardizzata e indipendente dal linguaggio per la descrizione delle API REST. È un formato leggibile sia dall'uomo che dalla macchina per tutte le operazioni di un'API, i suoi parametri, i tipi di dati di input e output, i metodi di autenticazione e altro ancora. Pensala come un contratto formale per la tua API: definisce esattamente cosa fa, come si comporta e cosa ci si può aspettare da essa.

Storia e Versioni

Originariamente nota come Swagger Specification, è stata donata da SmartBear Software alla Linux Foundation nel 2015, dove è stata ribattezzata OpenAPI Specification e gestita da un consorzio di aziende e individui. Questo passaggio ha segnato un'importante evoluzione, promuovendo l'adozione su larga scala e la collaborazione della comunità.

Le versioni più comuni che potresti incontrare sono:

• OpenAPI 2.0 (precedentemente Swagger Specification 2.0): La versione storica, ancora molto diffusa. Utilizza un approccio leggermente diverso per definire gli schemi e le risposte rispetto alle versioni più recenti.
• OpenAPI 3.x: La versione attuale e raccomandata. Introduce miglioramenti significativi nella modularità, nella gestione degli schemi, nella descrizione dei callback, dei link e nella gestione dell'autenticazione. Le versioni 3.0, 3.0.x e 3.1.0 (che supporta la specifica JSON Schema 2020-12) sono le più recenti e offrono maggiore flessibilità e potenza.

È cruciale capire che, sebbene ci siano differenze sintattiche, il principio fondamentale rimane lo stesso: descrivere l'API in modo standardizzato. Quando si inizia un nuovo progetto, è sempre consigliabile utilizzare l'ultima versione stabile di OpenAPI (attualmente 3.x).

Struttura di Base di un File OpenAPI

Una specifica OpenAPI può essere scritta in formato YAML o JSON. YAML è spesso preferito per la sua leggibilità e concisione. I componenti chiave di una specifica OpenAPI includono:

• openapi: Specifica la versione di OpenAPI utilizzata (es. 3.0.0).
• info: Metadati dell'API come titolo, descrizione, versione e informazioni di contatto.
• servers: Un array di URL dei server a cui l'API è destinata (es. produzione, staging, sviluppo).
• paths: Il cuore della specifica, dove vengono definiti gli endpoint (path) e le operazioni HTTP (GET, POST, PUT, DELETE) per ciascun path.
• components: Un'area per definire schemi riutilizzabili (per modelli di dati), parametri, intestazioni, risposte e meccanismi di sicurezza. Questo promuove la riusabilità e la manutenibilità della specifica.
• security: Definisce i requisiti di sicurezza globali per l'API.
• tags: Permette di raggruppare operazioni correlate per una migliore organizzazione nella documentazione.

La modularità offerta da components è uno dei maggiori vantaggi di OpenAPI 3.x, consentendo di definire modelli di dati (schemi) una sola volta e riutilizzarli in più operazioni, rendendo la specifica più DRY (Don't Repeat Yourself) e facile da gestire.

Strumenti dell'Ecosistema Swagger

L'ecosistema Swagger è una suite di strumenti open source che implementano e sfruttano la specifica OpenAPI per aiutarti in ogni fase del ciclo di vita delle API. Questi strumenti sono progettati per lavorare insieme, fornendo un flusso di lavoro coeso per la progettazione, lo sviluppo, il testing e la documentazione delle API.

Swagger UI

Swagger UI è forse lo strumento più conosciuto e apprezzato dell'ecosistema. Prende un file OpenAPI (YAML o JSON) e lo trasforma in una documentazione API interattiva e visivamente accattivante, che può essere esplorata direttamente nel browser. Offre:

• Visualizzazione Chiare: Mostra tutti gli endpoint, i metodi HTTP, i parametri, i corpi delle richieste e delle risposte in un formato leggibile.
• Interattività: Permette agli sviluppatori di testare le API direttamente dalla documentazione, inviando richieste e visualizzando le risposte in tempo reale. Questo è incredibilmente utile per la fase di sviluppo e debug.
• Generazione Automatica: Una volta che hai una specifica OpenAPI valida, la documentazione è generata automaticamente e sempre aggiornata con la tua specifica.

Swagger Editor

Swagger Editor è un editor basato su browser che ti aiuta a scrivere e validare le tue specifiche OpenAPI. Offre funzionalità come:

• Validazione in Tempo Reale: Controlla la sintassi e la semantica della tua specifica mentre la scrivi, evidenziando errori e suggerendo correzioni.
• Autocompletamento: Aiuta a scrivere più velocemente e con meno errori, suggerendo i campi e i valori validi secondo la specifica OpenAPI.
• Anteprima Integrata: Spesso include una versione leggera di Swagger UI per visualizzare in anteprima come apparirà la documentazione della tua API mentre la stai creando.

È uno strumento prezioso per assicurarsi che la tua specifica sia sempre conforme agli standard e priva di errori prima di essere utilizzata per generare documentazione o codice.

Swagger Codegen

Swagger Codegen è uno strumento a riga di comando o una libreria che genera automaticamente codice client (SDK) e server (stub) in una moltitudine di linguaggi di programmazione, basandosi sulla tua specifica OpenAPI. Questo accelera significativamente lo sviluppo, riducendo il lavoro manuale e gli errori.

• Generazione Client: Crea librerie client specifiche per il linguaggio (es. JavaScript, Python, Java, C#) che gli sviluppatori possono usare per interagire con la tua API senza dover scrivere manualmente le chiamate HTTP.
• Generazione Server: Genera lo scheletro (stub) del codice del server, inclusi controller e modelli di dati, che gli sviluppatori possono poi implementare con la logica di business. Questo garantisce che l'implementazione del server sia perfettamente allineata con la specifica API.
• Supporto Multi-linguaggio: Supporta decine di linguaggi e framework, rendendolo estremamente versatile per team che lavorano con stack tecnologici diversi.

L'uso di Swagger Codegen garantisce che il codice client e server sia sempre sincronizzato con la specifica API, riducendo le frizioni e gli errori dovuti a discrepanze tra documentazione e implementazione.

Progettare la Tua API con OpenAPI: Un Approccio Guidato

La progettazione di un'API con OpenAPI è un processo iterativo che inizia con la definizione delle risorse e delle operazioni. Si tratta di pensare a come i consumatori interagiranno con la tua API e di tradurre quelle interazioni in un formato strutturato.

Definire Paths e Operazioni

Ogni endpoint della tua API è rappresentato da un path. Sotto ogni path, definisci le operazioni HTTP supportate (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD). Per ogni operazione, dovresti includere:

• summary e description: Brevi descrizioni per gli esseri umani.
• operationId: Un identificatore unico per l'operazione, utile per la generazione di codice.
• parameters: I parametri che l'operazione accetta.
• requestBody: La struttura del corpo della richiesta per le operazioni POST, PUT, PATCH.
• responses: Le possibili risposte dell'API, incluse le intestazioni e i corpi delle risposte per diversi codici di stato HTTP (es. 200 OK, 201 Created, 400 Bad Request, 404 Not Found).

Parametri (Path, Query, Header, Cookie)

OpenAPI supporta diversi tipi di parametri:

• path: Parte dell'URL (es. /users/{userId}). Sono obbligatori.
• query: Aggiunti all'URL dopo un ? (es. /users?status=active). Possono essere opzionali.
• header: Inviati nelle intestazioni HTTP della richiesta (es. Authorization).
• cookie: Inviati tramite i cookie HTTP.

Per ogni parametro, devi specificare il suo name, in (dove si trova), description, required (se è obbligatorio) e il suo schema (il tipo di dato, es. string, integer).

Corpi delle Richieste e delle Risposte (Schemi JSON)

Per le operazioni che inviano o ricevono dati nel corpo della richiesta/risposta (come POST, PUT, PATCH), devi definire la struttura di questi dati usando gli schemi. OpenAPI utilizza un sottoinsieme esteso di JSON Schema per descrivere la struttura dei tuoi dati.

Nel blocco components/schemas, puoi definire i tuoi modelli di dati riutilizzabili. Ad esempio, un modello Book potrebbe avere proprietà come id, title, author, publicationYear.

components:
  schemas:
    Book:
      type: object
      required:
        - title
        - author
      properties:
        id:
          type: integer
          format: int64
          readOnly: true
          description: ID unico del libro
        title:
          type: string
          description: Titolo del libro
          example: Il Signore degli Anelli
        author:
          type: string
          description: Autore del libro
          example: J.R.R. Tolkien
        publicationYear:
          type: integer
          description: Anno di pubblicazione
          example: 1954

Questi schemi possono poi essere referenziati nelle definizioni di requestBody e responses usando $ref: '#/components/schemas/Book', garantendo coerenza e riducendo la ridondanza.

Autenticazione e Sicurezza

Le API raramente sono completamente aperte. OpenAPI ti permette di definire vari meccanismi di sicurezza, come:

• API Key: Una chiave inviata in un header, query parameter o cookie.
• HTTP Basic/Bearer Authentication: Credenziali utente o token JWT nell'header Authorization.
• OAuth2: Per scenari di autorizzazione più complessi.

Questi schemi di sicurezza vengono definiti sotto components/securitySchemes e poi referenziati globalmente o per singola operazione nel blocco security.

Esempi Pratici: Costruire una Specifica OpenAPI per un'API di Libri

Creiamo una specifica OpenAPI 3.0.0 per una semplice API di gestione dei libri. Questa API permetterà di:

• Ottenere tutti i libri.
• Aggiungere un nuovo libro.
• Ottenere un libro per ID.
• Aggiornare un libro esistente.
• Eliminare un libro.

Questo esempio dimostrerà l'uso di path, operazioni, parametri, schemi e risposte.

openapi: 3.0.0
info:
  title: API per la Gestione dei Libri
  description: Un'API di esempio per gestire una collezione di libri.
  version: 1.0.0
servers:
  - url: http://localhost:3000/api/v1
    description: Server di sviluppo locale
  - url: https://api.example.com/api/v1
    description: Server di produzione
tags:
  - name: Books
    description: Operazioni relative ai libri
paths:
  /books:
    get:
      tags:
        - Books
      summary: Ottieni tutti i libri
      description: Restituisce una lista di tutti i libri presenti nel catalogo.
      operationId: getAllBooks
      parameters:
        - name: limit
          in: query
          description: Limite massimo di libri da restituire
          required: false
          schema:
            type: integer
            format: int32
            minimum: 1
            default: 10
        - name: offset
          in: query
          description: Numero di libri da saltare (per paginazione)
          required: false
          schema:
            type: integer
            format: int32
            minimum: 0
            default: 0
      responses:
        '200':
          description: Una lista di libri.
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Book'
              examples:
                success:
                  value:
                    - id: 1
                      title: Il Signore degli Anelli
                      author: J.R.R. Tolkien
                      publicationYear: 1954
                    - id: 2
                      title: 1984
                      author: George Orwell
                      publicationYear: 1949
        '500':
          description: Errore interno del server.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
    post:
      tags:
        - Books
      summary: Aggiungi un nuovo libro
      description: Crea un nuovo libro nel catalogo.
      operationId: createBook
      requestBody:
        description: Oggetto libro da creare
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/BookCreate'
            examples:
              newBook:
                value:
                  title: Fondazione
                  author: Isaac Asimov
                  publicationYear: 1951
      responses:
        '201':
          description: Libro creato con successo.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Book'
        '400':
          description: Dati di input non validi.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
  /books/{bookId}:
    get:
      tags:
        - Books
      summary: Ottieni un libro per ID
      description: Restituisce un singolo libro basato sul suo ID.
      operationId: getBookById
      parameters:
        - name: bookId
          in: path
          description: ID del libro da recuperare
          required: true
          schema:
            type: integer
            format: int64
      responses:
        '200':
          description: Dettagli del libro.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Book'
        '404':
          description: Libro non trovato.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
    put:
      tags:
        - Books
      summary: Aggiorna un libro esistente
      description: Aggiorna i dettagli di un libro specifico.
      operationId: updateBook
      parameters:
        - name: bookId
          in: path
          description: ID del libro da aggiornare
          required: true
          schema:
            type: integer
            format: int64
      requestBody:
        description: Oggetto libro con i dati aggiornati
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/BookCreate'
      responses:
        '200':
          description: Libro aggiornato con successo.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Book'
        '400':
          description: Dati di input non validi.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
        '404':
          description: Libro non trovato.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
    delete:
      tags:
        - Books
      summary: Elimina un libro
      description: Elimina un libro specifico dal catalogo.
      operationId: deleteBook
      parameters:
        - name: bookId
          in: path
          description: ID del libro da eliminare
          required: true
          schema:
            type: integer
            format: int64
      responses:
        '204':
          description: Libro eliminato con successo (No Content).
        '404':
          description: Libro non trovato.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
components:
  schemas:
    Book:
      type: object
      properties:
        id:
          type: integer
          format: int64
          readOnly: true
          description: ID unico del libro
          example: 1
        title:
          type: string
          description: Titolo del libro
          example: Il Signore degli Anelli
        author:
          type: string
          description: Autore del libro
          example: J.R.R. Tolkien
        publicationYear:
          type: integer
          description: Anno di pubblicazione
          example: 1954
    BookCreate:
      type: object
      required:
        - title
        - author
      properties:
        title:
          type: string
          description: Titolo del libro
          example: Il Signore degli Anelli
        author:
          type: string
          description: Autore del libro
          example: J.R.R. Tolkien
        publicationYear:
          type: integer
          description: Anno di pubblicazione
          example: 1954
    Error:
      type: object
      properties:
        code:
          type: integer
          format: int32
          example: 400
        message:
          type: string
          example: Richiesta non valida

Questo file YAML definisce una specifica completa per l'API dei libri. Puoi copiarla in Swagger Editor per visualizzarla e validarla immediatamente. Noterai l'uso di $ref per riutilizzare lo schema Book e Error, e l'inclusione di examples nelle risposte per rendere la documentazione ancora più utile.

Integrazione con i Framework Web

Una volta che hai una specifica OpenAPI, il passo successivo è renderla disponibile. Il modo più comune è integrare Swagger UI direttamente nella tua applicazione web, in modo che la documentazione sia sempre accessibile e aggiornata con il tuo codice.

Esempio con Node.js (Express)

Per un'applicazione Node.js basata su Express, puoi utilizzare librerie come swagger-ui-express o express-swagger-generator per servire la documentazione Swagger UI. swagger-ui-express è più semplice e richiede che tu abbia già un file OpenAPI (JSON/YAML), mentre express-swagger-generator può generare la specifica direttamente dal codice commentato.

Ecco un esempio di integrazione con swagger-ui-express:

1. Installa le dipendenze:

   npm install express swagger-ui-express yamljs
   

2. Crea un file openapi.yaml (usando la specifica dell'esempio precedente o una tua).
3. Configura Express per servire Swagger UI:

const express = require('express');
const swaggerUi = require('swagger-ui-express');
const YAML = require('yamljs');
const path = require('path');

const app = express();
const port = 3000;

// Carica il file OpenAPI YAML
const swaggerDocument = YAML.load(path.join(__dirname, './openapi.yaml'));

// Configura Swagger UI
app.use('/api-docs', swaggerUi.serve, swaggerUi.setup(swaggerDocument));

// Esempio di un endpoint API (non dettagliato, solo per dimostrazione)
app.get('/api/v1/books', (req, res) => {
  res.json([{ id: 1, title: 'Test Book', author: 'Test Author', publicationYear: 2023 }]);
});

app.listen(port, () => {
  console.log(`Server in ascolto su http://localhost:${port}`);
  console.log(`Documentazione API disponibile su http://localhost:${port}/api-docs`);
});

Dopo aver avviato questo server, potrai accedere alla documentazione interattiva della tua API visitando http://localhost:3000/api-docs nel tuo browser. Questa configurazione rende la documentazione una parte intrinseca della tua applicazione, sempre aggiornata e facilmente accessibile.

Integrazione in altri Framework

• Python (Flask/Django): Librerie come flask-restx (per Flask) o drf-spectacular (per Django REST Framework) permettono di generare automaticamente la specifica OpenAPI dal codice Python e di integrare Swagger UI.
• PHP (Laravel): Pacchetti come DarkaOnline/L5-Swagger consentono di generare la specifica da annotazioni PHP e di servire Swagger UI direttamente dalla tua applicazione Laravel.

L'approccio generale è simile: si genera o si carica la specifica OpenAPI e la si passa a un middleware che si occupa di servire l'interfaccia utente di Swagger.

Vantaggi e Best Practices nell'Uso di OpenAPI e Swagger

L'adozione di OpenAPI e Swagger porta con sé una moltitudine di vantaggi che migliorano l'intero ciclo di vita dello sviluppo delle API.

Vantaggi Chiave

1. Coerenza e Standardizzazione: Fornisce un formato standard per descrivere le API, garantendo coerenza nella progettazione e nella documentazione tra diversi team e progetti.
2. Migliore Collaborazione: Funge da linguaggio comune per sviluppatori frontend, backend, tester e product manager, riducendo incomprensioni e accelerando la comunicazione.
3. Documentazione Sempre Aggiornata: Con Swagger UI, la documentazione è generata automaticamente dalla specifica, garantendo che sia sempre allineata con l'implementazione corrente dell'API.
4. Generazione Automatica di Codice: Swagger Codegen consente di generare SDK client e stub server in vari linguaggi, riducendo il tempo di sviluppo e minimizzando gli errori manuali.
5. Testing Facilitato: La documentazione interattiva di Swagger UI permette di testare gli endpoint API direttamente dal browser, semplificando il debug e la validazione.
6. Design-First Approach: Incoraggia un approccio "Design-First", dove la specifica API viene definita e concordata prima di scrivere il codice, portando a API più robuste e ben pensate.
7. Onboarding Semplificato: I nuovi sviluppatori possono rapidamente comprendere e iniziare a utilizzare le API grazie alla documentazione chiara e interattiva.

Best Practices

• Design-First: Inizia sempre con la specifica OpenAPI. Discuti e valida la specifica con il tuo team prima di scrivere una singola riga di codice. Questo aiuta a prevenire costosi refactoring in seguito.
• Descrizioni Chiare e Dettagliate: Non lesinare su summary e description per path, operazioni, parametri e schemi. Più le descrizioni sono accurate e complete, più la documentazione sarà utile.
• Usa Esempi (Examples): Includi esempi realistici per i corpi delle richieste e delle risposte. Questo aiuta gli sviluppatori a capire rapidamente come interagire con la tua API e cosa aspettarsi.
• Riutilizzo con components: Sfrutta al massimo la sezione components per definire schemi, parametri e risposte riutilizzabili. Questo rende la tua specifica più modulare, leggibile e facile da mantenere.
• Definisci Tutti i Codici di Stato HTTP: Non limitarti a definire solo le risposte di successo (2xx). Includi anche i codici di errore (4xx, 5xx) con descrizioni e schemi di errore chiari.
• Versionamento delle API: Se la tua API evolve, considera il versionamento (es. /v1, /v2). Ogni versione può avere la sua specifica OpenAPI.
• Validazione Continua: Utilizza Swagger Editor o strumenti di validazione CI/CD per assicurarti che la tua specifica sia sempre valida e conforme agli standard OpenAPI.
• Sicurezza: Definisci chiaramente i meccanismi di autenticazione e autorizzazione richiesti per ogni endpoint.

Errori Comuni e Come Evitarli

Anche con strumenti potenti come OpenAPI e Swagger, è facile cadere in alcune trappole comuni. Essere consapevoli di questi errori può aiutarti a evitarli e a massimizzare i benefici.

1. Specifiche Incomplete o Non Aggiornate: L'errore più comune. Una specifica che non riflette lo stato attuale dell'API è peggio che non averne affatto, poiché porta a false aspettative e frustrazione. Soluzione: Integra la generazione o la validazione della specifica nel tuo pipeline CI/CD. Rendi la manutenzione della specifica parte integrante del processo di sviluppo.
2. Mancanza di Esempi nelle Risposte: Senza esempi, gli sviluppatori devono indovinare la struttura esatta dei dati. Soluzione: Aggiungi sempre esempi realistici per ogni schema di risposta, specialmente per i codici di stato di successo e di errore.
3. Specifiche Troppo Generiche o Troppo Dettagliate: Una specifica troppo vaga non fornisce abbastanza informazioni, mentre una troppo dettagliata può essere difficile da mantenere e leggere. Soluzione: Trova un equilibrio. Concentrati sulle informazioni essenziali per l'interazione con l'API, ma non omettere dettagli critici come i tipi di dati e la validazione.
4. Non Definire i Codici di Errore: Molti sviluppatori si concentrano solo sulle risposte di successo. Tuttavia, sapere come l'API segnala gli errori è fondamentale per una gestione robusta degli errori nel client. Soluzione: Definisci schemi per gli errori comuni (es. 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error) e referenziali nelle risposte appropriate.
5. Ignorare la Validazione: Non validare la specifica prima di distribuirla o usarla per generare codice può portare a problemi inaspettati. Soluzione: Utilizza Swagger Editor o un validatore CLI per assicurarti che la tua specifica sia sintatticamente e semanticamente corretta.
6. Nomi Incoerenti: Nomi di path, parametri o schemi incoerenti rendono l'API difficile da capire e utilizzare. Soluzione: Stabilisci convenzioni di denominazione chiare e seguile rigorosamente in tutta la specifica.

Prossimi Passi e Risorse per Approfondire

Questa guida ti ha fornito una solida base su OpenAPI e Swagger. Per approfondire ulteriormente e diventare un esperto, ecco alcuni prossimi passi e risorse:

1. Esplora la Documentazione Ufficiale: La documentazione di OpenAPI Specification e Swagger è la fonte più autorevole per dettagli e aggiornamenti. Visita https://swagger.io/specification/ e https://swagger.io/tools/.
2. Prova Strumenti Avanzati: Oltre a Swagger UI, Editor e Codegen, esistono altri strumenti nell'ecosistema, come SwaggerHub (una piattaforma completa per la gestione del ciclo di vita delle API basata su OpenAPI) o ReDoc (un'alternativa a Swagger UI con un'enfasi sulla leggibilità).
3. Design-First API Development: Approfondisci la metodologia di sviluppo