So, you have written a sizeable OpenAPI specification. At this point, you may have considered dividing the spec into smaller separate files to make the document more maintainable.

In this article, I break the typical PetStore example from the OpenAPI documentation into smaller files.

Note: Are you starting a new documentation project from scratch? At the end of the post, you will find a boilerplate ready to be adapted 😊

1. Reusing response objects

It is easier to start splitting an OpenAPI spec if you are already reusing objects. Imagine that you have documented a couple of endpoints when you notice that you are defining a response object that could be reused in other endpoints.

paths: /pets/{petId}: get: summary: Info for a specific pet operationId: showPetById parameters: - name: petId in: path required: true description: The id of the pet to retrieve schema: type: string responses: '200': description: Expected response to a valid request content: application/json: schema: type: object required: - id - name properties: id: type: integer format: int64 name: type: string tag: type: string

Following this example, if you were to create another endpoint to list pets, you could define a separate Pet object under component/schemas and reuse it in both endpoints.

The keyword $ref does the trick. It allows us to reference other components that are already defined within the specification.

paths: /pets/{petId}: get: summary: Info for a specific pet operationId: showPetById parameters: - name: petId in: path required: true description: The id of the pet to retrieve schema: type: string responses: '200': description: Expected response to a valid request content: application/json: schema: $ref: "#/components/schemas/Pet" components: schemas: Pet: type: object required: - id - name properties: id: type: integer format: int64 name: type: string tag: type: string

2. Reusing parameters objects

Now that you're comfortable reusing objects in the same file, let's make the petId parameter reusable.

As in the previous step, move the parameter from the path to the components/parameters section and use $ref to import the object. Here is an example:

paths: /pets/{petId}: get: summary: Info for a specific pet operationId: showPetById parameters: - $ref: '#/components/parameters/petId' [...] components: parameters: petId: name: petId in: path required: true description: The id of the pet to retrieve schema: type: string

3. Importing definitions from a separate file

Now that you are reusing definitions, the file should be shorter without even splitting it.

At this moment, you might already be pleased with the organization of the file, so you could decide to end reading the article here. However, if you want to continue moving parts of the spec into other files, keep reading!

Do you remember the keyword we have been using to reuse content? $ref not only allows us to import objects from the same file but from other sources like a separate file or a remote URL.

Create a new file schemas/Pet.yaml for the Pet object. Then, move the definition to the new file. Here's how the resulting file should look like:

// schemas/Pet.yaml type: object required: - id - name properties: id: type: integer format: int64 name: type: string tag: type: string

Now, point $ref to the new file's location.

// openapi.yaml $ref: "./schemas/Pet.yaml"

Finally, do the same for the other objects that you might want to split into separate files.

4. Dividing, even more, the specification

Until now, we have seen how to organize response objects and parameters. However, if you have several endpoints, you might continue having a large file that's challenging to maintain.

Next, we are going to organize the resource paths into multiple files.

For example, you could create the file path/pet.yaml. This file should define all the available methods, parameters, and responses for the endpoint/pets/{petId}:

//paths/pets.yaml get: summary: Info for a specific pet operationId: showPetById tags: - pets parameters: - $ref: "../parameters/path/petId.yaml" responses: '200': description: Expected response to a valid request content: application/json: schema: $ref: "../schemas/Pet.yaml" default: $ref: "../responses/UnexpectedError.yaml"

Then, import each path definition from the main OpenAPI spec as we have been doing with the schemas and parameters.

//openapi.yaml ... paths: /pets/{petId}: $ref: "./paths/pet.yaml

And, repeat the process for every other resource you want to import from a separate file.

5. Organizing the specification

Let's go one step further.

We can split even more our project to achieve a better organization, to end having a tiny main file like the following one.

// openapi.yaml openapi: "3.0.0" info: version: 1.0.0 title: Swagger Petstore description: Multi-file boilerplate for OpenAPI Specification. license: name: MIT servers: - url: http://petstore.swagger.io/v1 paths: /pets: $ref: "./paths/pets.yaml" /pets/{petId}: $ref: "./paths/pet.yaml" components: parameters: $ref: "./parameters/_index.yaml" schemas: $ref: "./schemas/_index.yaml" responses: $ref: "./responses/_index.yaml"

To achieve so, you will have to create new _index.yaml files containing each section's definitions. For instance, ./schemas/_index.yaml for the PetStore example would look like:

Pet: $ref: "./Pet.yaml" Pets: $ref: "./Pets.yaml" Error: $ref: "./Error.yaml"

6. From many files to one

Some of the OpenAPI based tools support just a single file as an input. To continue using the spec with those tools, we will compile all the different files we have created with the command-line tool swagger-cli.

1. Open a new terminal. Then, install the package swagger-cli globally:

npm install -g swagger-cli

2. Run the command to merge all the files into one:

swagger-cli bundle openapi.yaml --outfile _build/openapi.yaml --type yaml

3. If everything goes well, you should see the OpenAPI file compiled under the _build directory.

Putting all together

No one really wants to do a change in a file with +5000 lines of code without tests 🙈. By splitting a large OpenAPI spec into multiple files, your project becomes much more maintainable and the documentation journey enjoyable. In my case, I have also noticed that other developers are more willing to contribute and propose changes to the document when this is properly organized.

As promised, I'm sharing with you a repository with the PetStore example divided into multiple files. Feel free to reuse the project to define your OpenAPI spec and review how the explanations from this article have been put into practice.

Repository: openapi-boilerplate