[opensourcedex]

OpenAPI-Specification is a free, open source api development & testing project written in Markdown and released under Apache-2.0. It has 31,215 GitHub stars, 9,156 forks and 80 open issues, and was last pushed 6 days ago. On this registry it ranks #6 of 103 tracked projects in API Development & Testing, with 5 head-to-head comparisons available. It gained 2 stars over the last 3 tracked days.

What is OpenAPI-Specification?

What it is

The OpenAPI Specification (OAS) is a community-driven open specification hosted within the OpenAPI Initiative, a Linux Foundation Collaborative Project. It defines a standard, programming language-agnostic interface description for HTTP APIs, represented in YAML or JSON. The specification lives in the HTTP API tooling ecosystem, alongside the tools, libraries, and implementations listed in the repository's implementations document. The project source is released under the Apache-2.0 license, and its GitHub repository has accumulated roughly 31,000 stars and 9,100 forks across 13 years of activity.

The concrete problem it solves is the guesswork involved in calling a service. Without a machine-readable description, a consumer must read source code, hunt for separate documentation, or inspect network traffic to learn what an API does. OpenAPI documents let both humans and computers discover and understand the capabilities of a service directly, so a consumer can interact with a remote service using a minimal amount of implementation logic. The specification applies to existing APIs without requiring them to be rewritten, and it does not require binding any software to the service; the described service may not even be owned by the author of its description.

Key capabilities

  • Defines a programming language-agnostic interface description for HTTP APIs, expressed in YAML or JSON.
  • Supports interactive documentation generated from machine-readable API definition documents.
  • Enables code generation for documentation, clients, and servers.
  • Supports automation of test cases from the same definitions.
  • Allows documents to be produced and served statically, or generated dynamically from an application.
  • Includes support for REST APIs as a described style.
  • Does not mandate a specific development process such as design-first or code-first, facilitating either technique.

Who uses it and how

  • API consumers read a description to understand and interact with a remote service with minimal implementation logic.
  • Tool and library authors create, present, and otherwise use OpenAPI definitions, tracked in the repository's implementations list.
  • Teams generate documentation, client code, and server code from a single API definition.
  • Teams automate test cases against definitions rather than hand-written expectations.
  • Maintainers and committers develop
project readme (upstream, from github) — read inline

The OpenAPI Specification

Build Status Issue triagers

OpenAPI logo

The OpenAPI Specification is a community-driven open specification within the OpenAPI Initiative, a Linux Foundation Collaborative Project.

The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs. This allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenAPI Specification removes guesswork in calling a service.

Use cases for machine-readable API definition documents include, but are not limited to: interactive documentation; code generation for documentation, clients, and servers; and automation of test cases. OpenAPI documents describe API services and are represented in YAML or JSON formats. These documents may be produced and served statically or generated dynamically from an application.

The OpenAPI Specification does not require rewriting existing APIs. It does not require binding any software to a service – the described service may not even be owned by the creator of its description. It does, however, require that the service's capabilities be described in the structure of the OpenAPI Specification. Not all services can be described by OpenAPI – this specification is not intended to cover every possible style of HTTP APIs, but does include support for REST APIs. The OpenAPI Specification does not mandate a specific development process such as design-first or code-first. It does facilitate either technique by establishing clear interactions with an HTTP API.

This GitHub project is the starting point for OpenAPI. Here you will find the information you need about the OpenAPI Specification, simple examples of what it looks like, and some general information regarding the project.

Versions

This repository contains the Markdown sources for all published OpenAPI Specification versions. For release notes and release candidate versions, refer to the releases page.

See It in Action

If you just want to see it work, check out the list of current examples.

Tools and Libraries

Looking to see how you can create your own OpenAPI definition, present it, or otherwise use it? Check out the growing list of implementations.

Participation

The current process for developing the OpenAPI Specification is described in the Contributing Guidelines.

Build, test, schema publication, and release command infrastructure is shared with other OpenAPI Initiative specification repositories through OAI/build-infra. See that repository's README and CONTRIBUTING guide for details on the shared tooling.

Developing the next version of the OpenAPI Specification is guided by the Technical Steering Committee (TSC). This group of committers bring their API expertise, incorporate feedback from the community, and expand the group of committers as appropriate. All development activity on the future specification will be performed as features and merged into this branch. Upon release of the future specification, this branch will be merged to main.

The TSC holds weekly web conferences to review open pull requests and discuss open issues related to the evolving OpenAPI Specification. Participation in weekly calls and scheduled working sessions is open to the community. You can view the entire OpenAPI technical meeting calendar online.

The OpenAPI Initiative encourages participation from individuals and companies alike. If you want to participate in the evolution of the OpenAPI Specification, consider taking the following actions:

  • Review the specification markdown sources and authoritative source-of-truth HTML renderings, including full credits and citations.
  • Review the contributing process so you understand how the spec is evolving.
  • Check the discussions, issues and pull requests to see if someone has already documented your idea or feedback on the specification. You can follow an existing conversation by subscribing to the existing issue or PR.
  • Subscribe to an open issue a day (or a week) in your inbox via CodeTriage.com.
  • Create a discussion to describe a new concern, ideally with clear explanations of related use cases.

Not all feedback can be accommodated, and there may be solid arguments for or against a change being appropriate for the specification.

Licensing

See: License (Apache-2.0)

Frequently asked questions

Is OpenAPI-Specification free to use?

OpenAPI-Specification is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does OpenAPI-Specification do?

The OpenAPI Specification Repository

What is OpenAPI-Specification written in?

OpenAPI-Specification is primarily written in Markdown. Its source is publicly available at https://github.com/OAI/OpenAPI-Specification, and it has 31,215 GitHub stars.