How to Write Your First OpenAPI Specification Tyler Charboneau November 5, 2020 REST is the undisputed, go-to architecture for the vast majority of today’s APIs — facilitating simplified-and-efficient design for developers of all aptitudes. Millions of APIs can attribute their existence to the popularity of REST. With so many APIs flooding the market, establishing standardization can enhance overall API quality and make integrations easier.Knowing this, the API industry has coalesced around Open API Specification (OAS). The OpenAPI Specification outlines how REST APIs should be developed, delivered, and functioned. The framework redefines how developers approach the entire API lifecycle. If you’re hoping to learn the fundamentals behind OAS and why it’s useful, follow along below in our starter guide.OpenAPI Specification AdvantagesOpenAPI, the industry-standard API definition format.OAS development is inherently definition-based, meaning that the API interface takes precedence over all other life cycle stages. This means crafting requests, responses, and sets of endpoints. The specification emphasizes sound design over business logic — ultimately boosting your final product’s consumer-friendliness. Other methodologies might force you to make concessions in this area, to battle time constraints, and balance competing priorities.What are some other key advantages of the OpenAPI Specification?Human and machine-readable – easy to understand without access to source codeLanguage agnosticism and compatibility with most technology stacksOpen source and backed by the Linux FoundationDefinition-first development, even taken from your existing APIsSynchronized design, documentation, and implementation, automaticallyInspired a bustling community of global developers, backed by all major API platformsThe creators of OAS claim that it makes API development intuitive. Tools give real-time feedback, enable autofill, and support solo or team-based work. Automation, testing, and monitoring also lie at the heart of the OAS developer experience. So, where do we begin?Introducing SwaggerThere’s no better tool for designing OAS APIs than Swagger — a tooling system built from the ground up to support OpenAPI. Swagger’s ecosystem encourages remote collaboration, yet welcomes lone-wolf developers to the party. Swagger itself is split into different workspaces which power each development stage:The Swagger EditorUsers of an IDE or coding application like Visual Studio Code will feel right at home within the Swagger Editor. This workspace is where you’ll create your API definitions. You also might notice that the right-hand pane hosts your structures — displaying POST, GET, and other OAS-compliant API requests: Adjacent is Swagger Petstore, a sample server that makes it easy to test authorization filters and other controls. This is made possible via special-key. The editor is a workspace like any other; feel free to open recent projects or kick off a new project. The edit menu allows you to convert your JSON definitions into YAML. Once you’ve got a functional architecture, the Editor interface will enable you to confirm various design parameters then execute. This baked-in testing demonstrates how your OAS API might operate, especially as it’s tweaked continuously.The Swagger Editor is browser-based and supports JSON and YAML serialization within. This makes it easier to interpret your request data from a readable format. Proprietary or obscure languages would otherwise complicate this process. Requests are made in JSON, while responses are either in JSON or XML. Since the Editor is hosted on GitHub, you can also use it offline.Designing a PUT request is simple within the Editor. Image courtesy of Swagger.Designing a PUT request is simple within the Editor. Image courtesy of Swagger.While writing your definitions, the Editor will automatically parse your code for errors, seek opportunities to autofill, and highlight syntax in an organized fashion.Despite what we’ve shown you in our example (the Swagger Petstore API), a fresh workspace looks like you’d expect — a blank pane. You may clear any existing placeholder text using File -> Clear editor before you start writing. Building a specification requires some simple setup. You must define a title, description, and version number for your API. You also must indicate which Swagger version you’re using in the type field:This will be your starting point (otherwise customized to your project) when crafting your API definitions. Image courtesy of BlazeMeter.You’ll notice that these inputs will be output visually on the rightward pane. This allows you to track changes as you make them and evaluate their impacts continually. Swagger’s error alert box will illuminate immediate need areas — preventing problems from making it into production. The same pane also displays the formats and model types you might rely upon in the design phase, including:OrderCategoryUserTagPetApiResponseThankfully, the visual layout of your controls within the editor is clutter-free and logically color-coded. It’s relatively easy to pick out crucial information, and the GUI is navigable. There’s more than just drop-downs and accordion menus, however. You may directly edit your values manually if changes need to be made. This approach effectively blends configurability with user-friendliness. The layout is otherwise known as Swagger UI.Swagger CodegenImage courtesy of Swagger.Codegen is centered on one thing: streamlining the build process via the generation of SDKs and server stubs. This automated code creation works for any API. Whether you’re monetizing your API or not, Codegen will help it reach the market faster. While building an API, it’s also essential to understand hosting — where will your data be stored, and how can you design a suitable conduit through which requests may be routed?Codegen answers these questions by “generating boilerplate server code in over 20 different languages.” Folks often view server configuration as a tedious, complicated task left only to experts. Codegen tooling bridges the knowledge gap by making things easier for developers of all skill levels. Swagger’s process in this regard is low-code; they claim it only takes a few clicks.You’ll probably want your API to be consumed by as many people as possible, especially if it’s public. SDKs are instructions for external professionals that drive integration and improve understanding of your API product. Swagger Codegen produces SDKs in over 40 languages.Swagger’s server tool supports both OAS 2.0 and 3.0 APIs.Understanding SwaggerHubSwaggerHub was made for teams (and enterprises), promising easy collaboration and API alignment with business goals. Stakeholders from multiple groups can simultaneously inspect, comment on, and edit OAS APIs while they’re being created. We know that OAS is all about standards, which is why SwaggerHub can steadfastly uphold these standards in real-time.Teams love two things: examples and reusability. The former lets teams see how an API is coming together while testing functionality using calls and returns. These test servers can show you where optimizations are necessary within your structure. For example, you wouldn’t want to publish an API with endpoints that don’t match data types, objects, and arrays. Your API wouldn’t work effectively if these schemas aren’t adequate. On the reusability front, you can save components that may be useful within other API specifications.What else can you do with SwaggerHub?Access and team management, including project ownership delegationFork, compare, and merge codeTrack issues alongside the editor for better contextAPI definition syncing with source repositories and gatewaysSwaggerHub is a powerful way to make your API design process more inclusive.Swagger Tools: A Powerful OpenAPI SuiteSwagger is synonymous with sound OAS API design, and becoming acquainted with its tools will make the process that much easier. While Swagger’s components may not be perfect for complete beginners, even novice developers will appreciate many of Swagger’s low-code options. You might not even start from scratch — Swagger provides clear instructions on building from existing APIs within its documentation.If you want to create a REST API with ultimate compatibility, then the OpenAPI Specification should be your guiding light.