OpenAPI Specification
OAS 3.1.1 Released!
Die OpenAPI-Spezifikation ist eine Community-gesteuerte offene Spezifikation in der OpenAPI-Initiative, einem Kollaborativprojekt für Linux Foundation.
Die OpenAPI-Spezifikation (OAS) definiert eine Standardbeschreibung der Programmiersprache-Agnostic-Schnittstelle für HTTP-APIs. Dies ermöglicht es sowohl Menschen als auch Computern, die Fähigkeiten eines Dienstes zu ermitteln und zu verstehen, ohne den Zugriff auf Quellcode, zusätzliche Dokumentation oder Inspektion des Netzwerkverkehrs zu erfordern. Wenn ein Verbraucher über OpenAPI ordnungsgemäß definiert ist, kann er den Remote -Dienst mit einer minimalen Auswahl an Implementierungslogik verstehen und mit ihnen interagieren. Ähnlich wie bei den Schnittstellenbeschreibungen für die Programmierung niedrigerer Ebene wird die OpenAPI-Spezifikation beim Aufrufen eines Dienstes erraten.
Anwendungsfälle für maschinenlesbare API-Definitionsdokumente umfassen, ohne darauf beschränkt zu sein: Interaktive Dokumentation; Codegenerierung für Dokumentation, Clients und Server; und Automatisierung von Testfällen. OpenAPI -Dokumente beschreiben API -Dienste und sind in YAML- oder JSON -Formaten dargestellt. Diese Dokumente können statisch erstellt und dynamisch aus einer Anwendung erstellt werden.
Die OpenAPI -Spezifikation erfordert keine Umschreibung vorhandener APIs. Es erfordert keine Software an einen Dienst - der beschriebene Dienst ist möglicherweise nicht einmal dem Schöpfer seiner Beschreibung. Es erfordert jedoch, dass die Fähigkeiten des Dienstes in der Struktur der OpenAPI -Spezifikation beschrieben werden. Nicht alle Dienste können von OpenAPI beschrieben werden - diese Spezifikation soll nicht jeden möglichen Stil von HTTP -APIs abdecken, sondern beinhaltet die Unterstützung für REST -APIs. Die OpenAPI-Spezifikation schreibt keinen spezifischen Entwicklungsprozess wie Design-First oder Code First vor. Es erleichtert eine der beiden Techniken, indem es klare Wechselwirkungen mit einer HTTP -API erstellt.
Dieses GitHub -Projekt ist der Ausgangspunkt für OpenAPI. Hier finden Sie die Informationen, die Sie über die OpenAPI -Spezifikation benötigen, einfache Beispiele dafür, wie es aussieht, und einige allgemeine Informationen zum Projekt.
Dieses Repository enthält die Markdown -Quellen für alle veröffentlichten OpenAPI -Spezifikationsversionen. Für Versionshinweise und Veröffentlichung von Kandidatenversionen finden Sie auf der Seite "Releases".
Jeder Ordner in diesem Repository, wie z. B. Schemata und Tests, sollte Ordner im Zusammenhang mit den aktuellen und früheren Versionen der Spezifikation enthalten.
Wenn Sie nur sehen möchten, dass es funktioniert, lesen Sie die Liste der aktuellen Beispiele.
Suchen Sie, wie Sie Ihre eigene OpenAPI -Definition erstellen, sie präsentieren oder auf andere Weise verwenden können? Schauen Sie sich die wachsende Liste der Implementierungen an.
Der aktuelle Prozess zur Entwicklung der OpenAPI -Spezifikation wird in den beitragenden Richtlinien beschrieben.
Die Entwicklung der nächsten Version der OpenAPI -Spezifikation wird vom technischen Lenkungsausschuss (TSC) geleitet. Diese Gruppe von Ausschüssen bringt ihre API -Expertise mit, enthält Feedback aus der Community und erweitert die Gruppe der Ausschüsse gegebenenfalls. Alle Entwicklungsaktivitäten zur zukünftigen Spezifikation werden als Merkmale durchgeführt und in diesen Zweig zusammengefasst. Bei der Veröffentlichung der zukünftigen Spezifikation wird dieser Zweig zu main fusioniert.
Der TSC hält wöchentliche Webkonferenzen, um offene Pull -Anfragen zu überprüfen und offene Probleme im Zusammenhang mit der sich entwickelnden OpenAPI -Spezifikation zu erörtern. Die Teilnahme an wöchentlichen Anrufen und geplanten Arbeitssitzungen steht der Community offen. Sie können den gesamten Kalender für technische Besprechungen im OpenAPI -Meeting online anzeigen.
Die OpenAPI -Initiative fördert die Teilnahme von Einzelpersonen und Unternehmen gleichermaßen. Wenn Sie an der Entwicklung der OpenAPI -Spezifikation teilnehmen möchten, sollten Sie die folgenden Maßnahmen ergreifen:
Nicht alle Feedback können berücksichtigt werden, und es kann solide Argumente für oder gegen eine Änderung für die Spezifikation geben.
Siehe: Lizenz (Apache-2.0)
