Validatore di spec OpenAPI online

Incolla qui sopra la tua spec OpenAPI o Swagger per ottenere un elenco di errori e avvisi. Questa pagina spiega il significato di ogni messaggio e come risolverlo, così passi in fretta da un report rosso a uno pulito. Gli errori rendono il documento non valido; gli avvisi no.

Come controllare una spec e agire sul report

  1. 1

    Incolla la spec

    Incolla il documento in JSON o YAML nel campo.

  2. 2

    Apri i risultati

    Passa al passaggio dei risultati per vedere un messaggio di validità oppure un elenco di errori.

  3. 3

    Abbina ogni messaggio

    Trova il messaggio nella tabella qui sotto e applica la correzione nel tuo file sorgente.

  4. 4

    Incolla di nuovo

    Ripeti finché non restano errori, poi decidi quali avvisi vale la pena correggere.

Come leggere i messaggi di errore

Messaggio Significato Correzione
Impossibile leggere come JSON o YAML. Il testo non è leggibile in nessuno dei due formati Correggi la sintassi: virgole in eccesso, indentazione errata, graffe non chiuse
Campo di versione ‘openapi’ o ‘swagger’ mancante. Nessuna chiave di versione al primo livello Aggiungi openapi: 3.0.3 oppure swagger: "2.0"
Oggetto ‘info’ mancante. Nessuna sezione info Aggiungi info con titolo e versione
info.title è obbligatorio. info non ha un titolo Aggiungi un title sotto info
info.version è obbligatorio. info non ha una versione Aggiungi una version sotto info (la versione della tua API)
Oggetto ‘paths’ mancante. Nessuna sezione paths Aggiungi paths, anche vuoto all’inizio

Gli errori decidono se il documento viene considerato valido. Risolvili tutti per primi.

Come leggere gli avvisi

Messaggio Significato Correzione
Il percorso ‘x’ dovrebbe iniziare con ‘/’. Una chiave sotto paths non ha la barra iniziale Rinominala in /x
Metodo sconosciuto ‘x’ su /percorso. Una chiave sotto un percorso non è nell’elenco noto Controlla un eventuale refuso, oppure ignora se è un’estensione voluta o trace

L’elenco noto comprende get, post, put, patch, delete, head, options, parameters, summary, description e servers. Le estensioni del fornitore che iniziano con x- non vi compaiono, quindi risultano anch’esse come avvisi.

Cosa non può dirti un controllo online

Il report copre solo la struttura. Non segue i collegamenti $ref, non controlla le definizioni degli schema e non segnala gli operationId mancanti. Considera un esito positivo come la conferma che il file ha la forma di un documento OpenAPI, e usa un linter completo prima di pubblicare documentazione o generare codice client.

Consigli per lavorare su un report lungo

Parti dall’alto: un errore di parsing significa che il resto non è affidabile, quindi va risolto per primo. Poi sistema i campi di primo livello mancanti, che sono rapidi da aggiungere. Solo dopo guarda gli avvisi sui percorsi. Dopo ogni giro di modifiche, incolla di nuovo l’intero file e non un frammento, perché i controlli hanno bisogno del documento completo per trovare info e paths. Un report senza errori e con qualche avviso voluto è un punto di arrivo normale e accettabile.

Domande frequenti

Gli errori indicano che il documento non è valido. Gli avvisi segnalano elementi da controllare, come un percorso senza barra iniziale, ma non cambiano il risultato di validità.

Non necessariamente. Significa che la struttura di primo livello è a posto. Schema, riferimenti e risposte non vengono esaminati.

Le chiavi sotto un percorso vengono confrontate con un elenco fisso di metodi HTTP e di alcuni campi dell’elemento di percorso. Una chiave x- non vi compare, quindi viene segnalata come avviso. Puoi lasciarla dov’è.

No. Seguono l’ordine dei controlli: prima il campo version, poi info, infine paths. Non ci sono numeri di riga.

Strumenti correlati

Strumento disponibile in altre lingue

Guide e casi d'uso