OpenAPI Specification: Difference between revisions

Content deleted Content added
Fix reference I broke. More consistent terminology, update references, delete stale links. Remove promotional-sounding text about Swagger's current offerings as only its historical role in the specification is relevant. Remove everything about "The OpenAPI Tools Organization" which is not in any way part of to the OpenAPI Initiative.
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5
 
(9 intermediate revisions by 6 users not shown)
Line 3:
| title = OpenAPI
| long_name = OpenAPI Specification
| image = OpenAPI Specification Logo Pantone.svg
| image_size =
| alt =
Line 13:
| year_started = {{Start date|2010}}
| first_published = {{Start date|2011|08|10|df=y}}
| version = 3.1.01
| version_date = {{Start date|20212024|0210|1524|df=y}}
| preview =
| preview_date =
Line 28:
| website = {{URL|https://openapis.org}}
}}
The '''OpenAPI Specification''', previously known as the '''Swagger Specification''', is a [[Specification (technical standard)|specification]] for a [[Machine-readable medium|machine-readable]] [[interface definition language]] for describing, producing, consuming and visualizing [[Web API|web services]].<ref name=started>{{cite web |title=OpenAPI Documentation: Getting Started |website=Learn OpenAPI |url=https://learn.openapis.org/ |publisher=The OpenAPI Initiative |access-date=2024-09-17}}</ref> PreviouslyOriginally partdeveloped ofto support the [[Swagger (software)|Swagger]] framework, it became a separate project in 2015, overseen by the OpenAPI Initiative, an open-source collaboration project of the [[Linux Foundation]].<ref>{{Cite web|url=https://www.linuxfoundation.org/press/press-release/new-collaborative-project-to-extend-swagger-specification-for-building-connected-applications-and-services|title=New Collaborative Project to Extend Swagger Specification for Building Connected Applications and Services|archive-url=https://web.archive.org/web/20231031170437/https://www.linuxfoundation.org/press/press-release/new-collaborative-project-to-extend-swagger-specification-for-building-connected-applications-and-services|archive-date=31 October 2023}}</ref><ref name="charter">{{cite web |title=OpenAPI Initiative Charter |url=https://www.openapis.org/participate/how-to-contribute/governance |website=OpenAPI Initiative |access-date=12 November 2019 |archive-date=26 January 2025 |archive-url=https://web.archive.org/web/20250126133749/https://www.openapis.org/participate/how-to-contribute/governance |url-status=dead }}</ref>
 
An OpenAPI Description (OAD)<ref name=glossary>{{cite web|title=OpenAPI Documentation: Glossary |website=Learn OpenAPI |url=https://learn.openapis.org/glossary.html |publisher=The OpenAPI Initiative |date=2023 |access-date=2024-09-17}}</ref> represents a formal description of an API that tools can use to generate code, documentation, test cases, and more.
 
==History==
[[File:OpenAPI Logo Pantone.svg|thumb|Logo of the OpenAPI Initiative, the organization that develops the OpenAPI specification under the [[Linux Foundation]]]]
[[Swagger (software)|Swagger]] development began in early 2010 by Tony Tam, who was working at online dictionary company [[Wordnik]].<ref>{{cite web|url=https://sdtimes.com/apis/swagger-creator-joins-smartbear/|title=Swagger creator joins SmartBear|date=28 September 2015 |access-date=August 6, 2019}}</ref>
 
In March 2015, [[SmartBear Software]] acquired the open-source Swagger API specification from Reverb Technologies, Wordnik's parent company.<ref>{{Cite web|title = SmartBear Assumes Sponsorship of Swagger API Open Source Project|url=https://smartbear.com/news/news-releases/sponsorship-of-swagger/|website = SmartBear|access-date = 2015-03-25}}</ref>
Line 41 ⟶ 42:
On 1 January 2016, the Swagger specification was renamed the OpenAPI Specification (OAS) and was moved to a new [[GitHub]] [[Software repository|repository]].<ref>{{cite web |last1=OpenAPI Initiative |title=OpenAPI Specification |url=https://github.com/OAI/OpenAPI-Specification |website=GitHub |access-date=12 November 2019}}</ref>
 
In July 2017, the OpenAPI Initiative released version 3.0.0 of its specification.<ref>{{Cite web|url=https://www.openapis.org/blog/2017/07/26/the-oai-announces-the-openapi-specification-3-0-0 |date=July 26, 2017 |title=The OAI Announces the OpenAPI Specification 3.0.0|website=OpenAPIs|access-date=2018-04-19}}</ref> [[MuleSoft]], the main contributor to the alternative [[RESTful API Modeling Language]] (RAML), joined the OAS and open-sourced its API Modeling Framework tool, which can generate OAS documents from RAML input.<ref>{{Cite web|url=https://www.infoq.com/news/2017/05/api-raml-oas |first1=Abel |last1=Avram |date=May 6, 2017 |title=The HTTP API space is Consolidating around OAS|website=InfoQ|access-date=2017-05-14}}</ref>
 
In February 2021, the OpenAPI Initiative released version 3.1.0.<ref>{{Cite web|url=https://www.linux.com/news/openapi-specification-3-1-0-available-now |date=April 26, 2021 |title=OpenAPI Specification 3.1.0 Available Now|website=Linux.com|access-date=2021-04-26}}</ref> Major changes in OpenAPI Specification 3.1.0 include JSON schema vocabularies alignment, new top-level elements for describing webhooks that are registered and managed out of band, support for identifying API licenses using the standard SPDX identifier, allowance of descriptions alongside the use of schema references and a change to make the PathItems object optional to simplify creation of reusable libraries of components.<ref>{{Cite web|url=https://nordicapis.com/whats-new-in-openapi-3-1-0/ |first1=Tyler |last1=Charboneau |date=April 7, 2021 |title=What's New in OpenAPI 3.1.0?|website=Nordic APIs|access-date=2021-04-07}}</ref><ref>{{Cite web|url=https://www.openapis.org/blog/2021/02/18/openapi-specification-3-1-released |date=February 18, 2021 |title=OpenAPI Specification 3.1.0 Released|website=OpenAPI Initiative|access-date=2021-02-18}}</ref><ref>{{Cite web|url=https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0 |first1=Phil |last1=Sturgeon |date=February 16, 2021 |title=Migrating from OpenAPI 3.0 to 3.1.0|website=OpenAPI Initiative|access-date=2021-02-16}}</ref>
 
===Consolidation of Formats===
==Release dates==
 
Two somewhat similar technologies, [[MuleSoft]]'s [[RESTful API Modeling Language]] (RAML) and Apiary's API Blueprint, had been developed around the same time as what was then still called the Swagger Specification.
 
The producers of both formats later joined the OpenAPI Initiative: Apiary in 2016<ref>{{cite web|url=https://www.openapis.org/blog/2016/02/23/oai-update-new-members-openapi-spec-3-0-progress-and-more |website=The OpenAPI Initiative|title=OAI Update – new members, OpenAPI Spec 3.0 progress, and more!|last=Lensmar |first=Ole |date=23 February 2016 |accessdate=13 October 2024}}</ref> and MuleSoft in 2017.<ref name=RAML>{{Cite web|url=https://www.infoq.com/news/2017/05/api-raml-oas |first1=Abel |last1=Avram |date=May 6, 2017 |title=The HTTP API space is Consolidating around OAS|website=InfoQ|access-date=2017-05-14}}</ref> Both have added support for the OAS.<ref>{{cite web|url=https://blog.apiary.io/We-ve-got-Swagger |website=Oracle Apiary |title=We've got Swagger|last=Nesetril |first=Jakub |date=18 January 2016 |accessdate=13 October 2024}}</ref><ref name=RAML />
 
===Release dates===
 
{| class="wikitable"
|-
! Version !! Date !! Notes<ref>{{cite web|url=https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md |website=GitHub |title=OpenAPI Specification Version 3.1.0|access-date=November 7, 2023}}</ref>
|-
|3.1.1
|2024-10-24
|Patch release of the OpenAPI Specification 3.1.1
|-
| 3.1.0 || 2021-02-15 || Release of the OpenAPI Specification 3.1.0
|-
|3.0.4
|2024-10-24
|Patch release of the OpenAPI Specification 3.0.4
|-
|3.0.3
Line 84 ⟶ 99:
 
===Relationships to software engineering practices===
The paradigm of agreeing on an API contract first and then programming business logic afterwards, in contrast to coding the program first and then writing a retrospective description of its behavior as the contract, is called contract-first development. Since the interface is determined before any code is written, downstream developers can [[Mock object|mock]] the [[Server (computing)|server]] behavior and start testing right away.<ref>{{Cite book |last=Preibisch |first=Sascha |url=https://www.worldcat.org/oclc/1076234393 |publisher=Apress |title=API Development: A Practical Guide for Business Implementation Success |date=2018 |isbn=978-1-4842-4140-0 |___location=[Berkeley, CA] |oclc=1076234393 |quote=Having the Swagger (or for that matter, any other machine-readable) document available, team members can start working on their part of the project at the same time.}}</ref> In this sense, contract-first development is also a practice of [[shift-left testing]].
 
==Features==
Line 122 ⟶ 137:
[[Category:Application programming interfaces]]
[[Category:Markup languages]]
[[Category:JSON]]