Walidator OpenAPI

Wklej dokument OpenAPI lub Swagger, w JSON albo YAML, a ten walidator sprawdzi jego podstawową strukturę. Potwierdza, że dokument się parsuje, że ma pole wersji openapi lub swagger, obiekt info z tytułem i wersją oraz obiekt paths, a następnie oznacza ścieżki niezaczynające się od ukośnika i nieznane metody HTTP. To szybka kontrola struktury, a nie pełny walidator JSON Schema.

Jak przebiega walidacja

  1. 1

    Wklej dokument

    JSON lub YAML, dla OpenAPI 2 (Swagger) lub OpenAPI 3.

  2. 2

    Sparsuj go

    Walidator parsuje dokument jako JSON, a w razie niepowodzenia przechodzi do parsowania YAML.

  3. 3

    Sprawdź wymagane pola

    Potwierdza pole wersji `openapi` lub `swagger`, obiekt `info` z `title` i `version` oraz obiekt `paths`.

  4. 4

    Przeskanuj ścieżki

    Każda ścieżka jest sprawdzana pod kątem początkowego ukośnika, a każdy klucz operacji porównywany ze znanymi metodami HTTP.

  5. 5

    Przeczytaj raport

    Błędy blokują poprawność; ostrzeżenia wskazują ścieżki bez początkowego ukośnika i nieznane metody.

Co sprawdza ten walidator

Kontrola Wynik przy niepowodzeniu
Dokument parsuje się jako JSON lub YAML Błąd
Jest pole openapi lub swagger Błąd
Jest obiekt info Błąd
Jest info.title Błąd
Jest info.version Błąd
Jest obiekt paths Błąd
Każda ścieżka zaczyna się od / Ostrzeżenie
Klucze operacji to znane metody HTTP Ostrzeżenie

Dokument, który przejdzie wszystkie błędy, jest zgłaszany jako poprawny strukturalnie. Ostrzeżenia nie blokują poprawności; wskazują rzeczy warte poprawy.

Czego nie sprawdza

To kontrola struktury, a nie pełny walidator specyfikacji. Nie:

  • waliduje każdego węzła względem oficjalnego JSON Schema dla twojej wersji;
  • rozwiązuje odwołań $ref ani nie potwierdza istnienia komponentów, na które wskazują;
  • sprawdza, czy parametry ścieżki są spójnie zadeklarowane i używane;
  • weryfikuje, czy wartości operationId istnieją lub są unikalne;
  • zgłasza numerów wierszy błędów.

Aby uzyskać taką głębię, uruchom dedykowany walidator CLI, taki jak redocly lint, swagger-cli validate lub spectral lint. Użyj tego narzędzia do szybkiej kontroli, zanim zatwierdzisz (commit) lub udostępnisz specyfikację.

Wersje OpenAPI w praktyce

Wersja Uwagi
Swagger 2.0 Wciąż szeroko wdrożona; używa swagger: "2.0"
OpenAPI 3.0.x Najczęstsza linia 3.x
OpenAPI 3.1.0 Zgodna z JSON Schema 2020-12

Ten walidator akceptuje pole openapi (3.x) albo pole swagger (2.0), więc wszystkie one przechodzą kontrolę wersji.

Minimalny dokument, który przechodzi

openapi: 3.0.3
info:
  title: Example API
  version: 1.0.0
paths:
  /users:
    get:
      summary: List users

Każde wymagane pole jest obecne, jedyna ścieżka zaczyna się od ukośnika, a get to znana metoda, więc dokument jest zgłaszany jako poprawny strukturalnie.

Najczęściej zadawane pytania

Swagger to pierwotna nazwa specyfikacji, przekazanej Linux Foundation w 2015 roku i przemianowanej na „OpenAPI” od wersji 3.0. „Swagger” odnosi się teraz do narzędzi (Swagger UI, Swagger Editor). Sama specyfikacja to OpenAPI. Ten walidator akceptuje zarówno pole wersji swagger (2.0), jak i openapi (3.x).

Nie. Sprawdza podstawową strukturę: że dokument się parsuje, ma pole wersji, obiekt info z tytułem i wersją oraz obiekt paths, i ostrzega o ścieżkach bez początkowego ukośnika i nieznanych metodach. Nie waliduje każdego węzła względem oficjalnego JSON Schema. Do tego użyj redocly lint lub spectral lint.

Nie. Nie podąża za odwołaniami $ref ani nie sprawdza, czy komponenty, na które wskazują, istnieją. Dla odwołań między plikami najpierw zbunduj dokument narzędziem takim jak redocly bundle lub swagger-cli bundle, a potem uruchom pełny walidator.

Nie. Sprawdza tylko wklejony dokument, a nie działający kod. Nie może stwierdzić, czy twoje API faktycznie zwraca to, co opisuje specyfikacja. Robią to narzędzia do testowania kontraktów, takie jak Dredd lub Schemathesis.

Powiązane narzędzia

Narzędzie jest dostępne w innych językach