Although I don’t work in road ecology or traffic engineering, the author somehow pulled me through 300 pages on this topic. He managed this not just through vivid language and diction, but by personally visiting places and telling stories about the specific challenges that animals, “carers,” forest service workers, and others faced as freeways and highways bisected and dissected their environments.
To use an analogy, suppose you’re a barista making espresso coffee. An AGI-capable robot trained as a barista is able to make all the coffee that a regular barista can make but twice as fast. Further, the Android barista can create exquisite espresso art in any shape that humans request, wowing them and making the experience novel. Soon the human barista is replaced. After all, the paying customer would rather pay $2.50 for a robot to make a latte instead of $5.00, especially when it tastes the same.
Most code samples in documentation are fairly basic, which is by design. Documentation tries to show the most common use of the API, not advanced scenarios for an enterprise-grade app whose complexity would easily overwhelm developers. (At that point, you end up with a sample app.)
With AI tools built directly into your authoring tool or IDE (such as VS Code), fixing simple doc bugs can become a mechanical, click-button task. Here’s the approach to fixing simple doc bugs:
(Note: The fact that I’m writing a book review on this topic might seem odd given that I usually focus on tech comm topics. However, I document APIs for getting map data into cars, so I sometimes read books related to the automotive and transportation domain. I also run a book club at work focused on these books.)
During the past few weeks, I’ve felt like my brain’s RPMs have been in the red zone. Granted, the constant stream of chaotic political news hasn’t helped—but regardless of current political events, I’m frequently checking the news, my email, and chat messages and operating in a mode that isn’t great. Reading long-form books has proven to be difficult. I run a book club at work focused on automotive and transportation books, and it took me two months to make it through a single book (granted, it was a 300-page historically dense book, but still).
“Biohacking” might be a pretentious cyber term for what is otherwise a straightforward experiment. For 10 days, I tracked my food and exercise levels while also wearing a continuous glucose monitor (CGM) to track my glucose levels. I then used AI to pair up the food + exercise with the glucose readings and perform an analysis about triggers for glucose spikes and recommendations to avoid them.
I want you to act as my AI stream journal (similar to a bullet journal), for the day. In this chat session, I’ll log 3 kinds of notes: tasks, thoughts, and events. Tasks are to-do list items. Thoughts are random ideas or notes I have. Events consist of food eaten, exercise, or descriptions of my internal states. The point is to have an easy way to dump all the scattered information in my head into a central log that you organize and analyze on my behalf.
Redocly provides a variety of tools for working with API docs. Using Redocly’s command-line tools, you can split the OpenAPI definition into many sub-files, and then later bundle up the discrete files into a single file during the publishing stage. You can generate your docs into one of the most attractive outputs available for REST API docs, including integration with conceptual topics as well. Redocly also offers more robust developer portals and SaaS offerings that cover the full authoring and publishing lifecycle.
Note that Redocly is one of the sponsors of my site.
Background about Redocly’s approach to simplifying the author experience with OpenAPI
Before Redocly became Redocly, the team worked on a product called Rebilly that included a 22,000 line OpenAPI definition file. Working in such a long file and authoring in YAML or JSON was especially challenging. Not only was maneuvering in a single massive file difficult, one small indentation error would require them to constantly troubleshoot syntax issues. (The single YAML file for all OpenAPI definition elements was analogous to software developers storing all code for an application in a single file — an unthinkable way of working with code.)
When Redocly innovated on their approach to simplifying OpenAPI spec development, instead of putting a graphical user interface (GUI) on top of the OpenAPI code and requiring users to write the OpenAPI definition in forms, menus, and other widgets, Redocly decided on a more docs-as-code approach that aligns with the developer audience.
Redocly developed command-line tools to split the OpenAPI definition into smaller files to make it easier to work with. Files are stored as separate files and referenced through JSON reference tag ($ref) in the main OpenAPI file. Working in smaller files reduces the likelihood of syntax issues and other formatting errors. It also makes it easier to focus on the content.
The CLI tools also let you check your OpenAPI definition against a ruleset to ensure you’re following best practices. You can configure the ruleset with different levels of strictness, either including or ignoring optional best practices in the OpenAPI specification. This linting lets you identify issues in your OpenAPI definition that might not technically be errors but would better if included.
When you’re ready to publish your OpenAPI definition, you can also use a command line tool to bundle the small files up into a single file again.
Overall, Redocly’s approach to simplifying the author experience with OpenAPI is based on the idea that API documentation should be treated as code. This means that it should be written in a plain text format, such as Markdown, and stored in a version control system, such as Git. This approach has a number of benefits, including:
It makes it easier for developers and technical writers to collaborate on API documentation.
It makes it easier to track changes to API documentation and roll back to previous versions if necessary.
It makes it easier to automate the process of building and deploying API documentation.
Overview of Redocly products
Redocly has a variety of products, so let’s first clarify these tools before diving more deeply into the tutorial.
API documentation product that generates interactive documentation from your OpenAPI definition. Includes an interactive API client with a three-panel layout for navigation, documentation, and examples. Supports OpenAPI 3.1, 3.0 and Swagger 2.0.
Create a visually appealing and interactive API reference for your users
Command-line tool for working with OpenAPI descriptions and API lifecycle operations including linting, enhancement, and bundling. Automates API guidelines and documentation generation.
Lint your OpenAPI definition for potential errors and inconsistencies
Unified platform that includes Redoc, Revel, and Reef for managing all API documentation needs.
Manage your entire API lifecycle in one central location
This article will focus mostly on the authoring experience working with the OpenAPI definition using the command line tools. For more details about Redocly’s Developer Portal and Workflows product, see the Products menu on Redocly’s site.
Redocly CLI Walkthrough tutorial
This tutorial will give you a sense of how the Redocly CLI tools work and how to publish the OpenAPI using Redoc. You’ll break up an OpenAPI file, make some changes, bundle it back up, and then publish it with Redoc. The tutorial has the following sections:
The sections aren’t necessarily sequential, but they proceed through Redocly’s tools in a logical way to become familiar with different aspects of the products. Also, the tutorial uses a sample OpenAPI definition related to the OpenWeatherMap API (used elsewhere in the course). Also, the instructions were written using a Mac. There might not be any differences with Windows, but note that Windows wasn’t used here.
This tutorial is a brief exposure to Redocly’s tools only. For more comprehensive documentation, see Redocly’s documentation.
1. Install the prerequisites
Before you can work with the Redocly CLI tools, you need to install them. Node.js is a prerequisite.
If you’re starting a new API documentation project, you might want to use the openapi-starter template, which provides a pre-configured project structure. You can clone it or use it as a template on GitHub. However, in this tutorial, we’ll use the OpenWeatherMap OpenAPI file that we’ve been using in other places in this course.
2. Break up an OpenAPI file
In this step, you’ll break up an existing OpenAPI file into smaller files.
Right-click the file and choose Save Link As. Save it in a folder called redocly_project in a convenient location. This OpenAPI definition is a small OpenAPI 3.0 file for one API in the OpenWeatherMap API. Note that you can use another OpenAPI definition in this tutorial if you prefer. There’s nothing special about this file — it just gives us an OpenAPI definition to work with.
Open a terminal, browse to your redocly_project directory, and run the split command:
The original OpenAPI definition remains unchanged as openapi_openweathermap.yml. Redocly has extracted each of the paths, parameters, components, and other elements into individual files inside the openapi folder.
The new openapi.yml file in the openapi directory contains references to all the extracted files. For example:
...paths:/weather:$ref:paths/weather.yaml...
The weather path is now stored in openapi/paths/weather.yaml. When you open this weather.yaml file, you’ll see that its parameters are also stored in external files:
validating /openapi/openapi.yml...
[1] openapi/openapi.yml:2:1 at #/info
Info object should contain `license` field.
1 | openapi: 3.0.2
2 | info:
3 | title: OpenWeatherMap API
4 | description: >-
Warning was generated by the info-license rule.
You can customize the linting behavior in several ways:
Use different rulesets: minimal, recommended, or recommended-strict.
Adjust rule severity levels: error, warn, or off.
Add custom rules or override existing ones.
For example, to use the minimal ruleset:
redocly lint --extends minimal
Or to make all warnings into errors:
redocly lint --extends recommended-strict
Before continuing, restore the license object in your openapi.yml file.
4. Preview the Redoc output
Redocly CLI includes a documentation preview server that automatically rebuilds when it detects changes in your OpenAPI files. Let’s see it in action:
Run the preview server:
redocly preview-docs openapi/openapi.yml
You’ll see output similar to this:
Using Redoc community edition.
Login with redocly login or use an enterprise license key to preview with the premium docs.
🔎 Preview server running at http://127.0.0.1:8080
Bundling...
👀 Watching openapi/openapi.yml and all related resources for changes
Created a bundle for main@v1 successfully
By default, you’ll be using the community edition of Redoc. The premium version (Redocly API Reference) includes additional features like the Try-it-out console, enhanced search, and improved performance.
The preview server automatically detects the change, rebuilds the documentation, and refreshes your browser.
When you’re done with the preview server, press Ctrl+C in your terminal to stop the preview server.
To use the premium features, you’ll need to authenticate with redocly login or use an API key. We’ll explore the premium version’s additional capabilities in 7. Explore the premium version: Redocly API Reference.
5. Bundle up the OpenAPI definition into a single file
When you’re ready to use your OpenAPI definition with other tools, you might need to combine all the separate files into a single file. Here’s how to create this bundle:
Run the bundle command:
redocly bundle openapi/openapi.yml -o dist.json
The -o dist.json specifies the output file. After running the command, you’ll see:
bundling openapi/openapi.yml...
📦 Created a bundle for openapi/openapi.yml at dist.json in 38ms.
Open dist.json to see the complete OpenAPI definition with all references resolved into a single file.
You can also bundle to YAML format by changing the extension: -o dist.yaml
6. Combine conceptual docs with reference docs
A common challenge in API documentation is combining conceptual content (like getting started guides and tutorials) with reference documentation. Redocly offers several ways to integrate this content. Let’s explore the simplest approach: using the OpenAPI description field with external Markdown.
In your openapi.yml file, update the info section, specifically the description field, to reference an external Markdown file:
Create description.md in your openapi folder with this structure:
# Getting Started
Get the current weather, daily forecast for 16 days, and a
three-hour-interval forecast for 5 days for your city.
## Authentication
Learn how to authenticate with our API.
# Usage Examples
Interactive maps show precipitation, clouds, pressure, wind around your location.
**Note**: This sample covers the `current` endpoint only.
Redoc comes in two versions: an open-source version (“Redoc community edition”) and a premium version (“Redocly API Reference Docs”). The open-source version provides core functionality for rendering OpenAPI definitions with a three-panel layout. The premium version includes additional features such as:
We’ve covered the basics in earlier steps. Now let’s explore some more advanced features available when you authenticate with Redocly. To access premium features, you’ll need to authenticate with redocly login or use an API key.
The response should indicate “Authorization confirmed.” See the login command for more details.
Start the Redocly preview server:
redocly preview-docs
Let’s try some of Redoc’s advanced features:
Add example code to your description.md file using the PullRight feature:
<PullRight>
Example API calls:
```bash
# Get weather by city
curl api.openweathermap.org/data/2.5/weather?q=London
# Get weather by coordinates
curl api.openweathermap.org/data/2.5/weather?lat=35&lon=139
</PullRight>
Enable interactive features in your .redocly.yaml:
Key features available in premium Redoc include the following:
Three-panel responsive design
Support for OpenAPI 3.1, 3.0, and Swagger 2.0
Code samples support through vendor extensions
High-level grouping in side menu with x-tagGroups
Integration with React applications
Enhanced customization options through configuration
For additional capabilities like hosted documentation, automated builds, and enhanced features, check out Redocly’s platform solutions.
Yes, I’ll update this section to align with current practices. Here’s my suggested revision:
8. Publish the reference output
So far we’ve been exploring the API reference output from within the preview server. Now let’s publish the reference output for hosting elsewhere:
Bundle the OpenAPI definition:
redocly bundle openapi/openapi.yml -o dist.json
Create a new directory called redoc and create an index.html file inside it.
Add this template to your index.html file:
<!DOCTYPE html><html><head><title>API Reference</title><!-- needed for adaptive design --><metacharset="utf-8"/><metaname="viewport"content="width=device-width, initial-scale=1"><linkhref="https://fonts.googleapis.com/css?family=Montserrat:300,400,700|Roboto:300,400,700"rel="stylesheet"><style>body{margin:0;padding:0;}</style></head><body><redocspec-url='dist.json'></redoc><script src="https://cdn.redoc.ly/redoc/latest/bundles/redoc.standalone.js"></script></body></html>
Move your dist.json file into the redoc folder.
To view the output locally, you can use the Redocly CL:
redocly preview-docs dist.json
You can customize your documentation with various configuration options. Common customizations include:
Theme colors and typography
Response example settings
Navigation behavior
Search functionality
For samples, check out Redoc in production from companies like Docker, Zuora, and others.
Conclusion
Redoc provides one of the most attractive and functional outputs for REST API documentation. The three-column layout, with navigation, content, and examples clearly separated, creates a documentation experience that has become somewhat of an industry standard.
The tool offers several advantages:
Clean, modern interface
Support for OpenAPI 3.1, 3.0, and Swagger 2.0
Extensive customization options
Command-line workflow integration
Active development and community support
While Swagger UI remains popular due to its long history in the API documentation space, Redoc has gained significant adoption due to its modern design and feature set. The CLI-based toolset supports a docs-as-code workflow, making it particularly appealing for teams already using version control and automation in their documentation process.
For organizations looking for additional features and support, Redocly’s platform offers enhanced capabilities including hosted documentation, automated builds, and team collaboration features. You can start a free trial here or learn more at Redocly.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.