The OpenAPI Specification is adored, and its usefulness has seen it be subject to sweeping adoption in recent years. It’s clear that many see the value of the OpenAPI Specification, and see value in its adoption.
As with any trend, there’s a certain amount of consideration that should be paid before adopting the solution carte blanche. Read more
In our recent post on tips for starting a public API journey we touched briefly on the idea of creating a style guide that helps API providers produce well-constructed and consistent APIs as part of their public API offering. The creation of an API style guide is, however relevant for API providers regardless of whether they are providing APIs externally or internally: It provides the context for their development efforts whether it be outsourced or created internally and is an important tool for achieving some level of governance across the organization. Read more
The most common API definition languages we spot in the wild are Swagger / OpenAPI Spec, RAML and API Blueprint. All three let you define your endpoints, your resources, your query or path parameters, your headers, status codes, security schemes, and more. Read more
Following the fanfare of its introduction in late 2015, the OpenAPI Initiative has now been in existence for six months. As discussed on their blog a great deal of progress has been made towards creating the governance structure that will help the OpenAPI Specification (OAS) move forwards, including a home on GitHub that has been steadily collecting new issues for consideration and possible inclusion in the next version. Read more
As the API community starts a new year, we do so with an increasingly wide choice of API description formats at our disposal. However, a development late last year promises to alter this landscape by introducing an initiative aimed at standardizing how APIs are described. Read more