I will cover as many features of the OpenAPI version 3.0.0 specification as possible in this article, but the most detail can be found in the specification itself. After walking through this tutorial, I encourage the reader to browse the specification in more detail. Instead, we are going to use Swagger to build a demo REST API which conforms to OpenAPI standards and syntax. The rules themselves are very detailed, and describing each one in this blog post would be redundant. You do not have to be familiar with every detail of the OpenAPI specification to develop an API which conforms to said specification. The exact rules defining OAS are on Github for any user to peruse, but tools like Swagger make conforming to these rules easy for anyone. This fact makes adhering to OAS standards very easy when using Swagger tools.
Furthermore, all Swagger tools support the OAS 3.0.n specification. These tools like Swagger Hub, Swagger Editor, Swagger UI, and Swagger Validator all work together to aid in developing proper APIs. Many of these tools are available on their website, or as we will shortly see as Docker containers.
Swagger is a company that creates and supports open source API development tools. Since the inception of this open source group, the OpenAPI Specification (OAS) has gone through 3 versions, the last two of which are fully supported by the Swagger API Editor. This initiative sought to codify and finalize a standard ruleset for REST API development. To fix this issue, a bunch of companies got together and created the OpenAPI Initiative. OpenAPI Initiative and SwaggerĪs REST APIs became more prevalent across the Internet, the standards used to develop them became more varied. I am speaking specifically about the Open API Specification and Swagger. The good news is there are specifications and tools which aid in the development of easy to use APIs that change as fast as your business. If a product is difficult to use it likely will not be used at all, especially if that product is an API. Poorly developed or poorly documented APIs which are susceptible to frequent changes or misleading design decisions are difficult to use.
This schism does not affect developers or architects it only affects the users of the API.
The skillsets and mindsets involved in creating APIs are different from those involved in developing the business logic which uses an API. Unfortunately, there are many programmers, start-ups, and full-fledged companies that do not adhere to proper API development and maintenance. The rise of serverless computing and platform agnostic, app-based services use has forced the casual developer to learn proper API development, a task usually reserved for platform architects.
0 kommentar(er)
