Open API Server Implementation Using OpenAPI Generator

1. Overview

As the name suggests, the OpenAPI Generator generates code from an OpenAPI specification. It can create code for client libraries, server stubs, documentation, and configuration.

It supports various languages and frameworks. Notably, there’s support for C++, C#, Java, PHP, Python, Ruby, Scala — almost all the widely used ones.

In this tutorial, we’ll learn how to implement a Spring-based server stub using OpenAPI Generator via its Maven plugin.

Other ways of using the generator are through its CLI or online tools.

2. YAML File

To begin, we’ll need a YAML file specifying the API. We’ll give it as input to our generator to produce a server stub.

Here’s a snippet of our petstore.yml:

openapi: "3.0.0"
paths:
  /pets:
    get:
      summary: List all pets
      operationId: listPets
      tags:
        - pets
      parameters:
        - name: limit
          in: query
          ...
      responses:
        ...
    post:
      summary: Create a pet
      operationId: createPets
      ...
  /pets/{petId}:
    get:
      summary: Info for a specific pet
      operationId: showPetById
      ...
components:
  schemas:
    Pet:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: integer
          format: int64
        name:
          type: string
        tag:
          type: string
    Error:
      type: object
      required:
        - code
        - message
      properties:
        code:
          type: integer
          format: int32
        message:
          type: string

3. Maven Dependencies

3.1. Plugin for OpenAPI Generator

Next, let’s add the Maven dependency for the generator plugin:

<plugin>
    <groupId>org.openapitools</groupId>
    <artifactId>openapi-generator-maven-plugin</artifactId>
    <version>7.8.0</version>
    <executions>
        <execution>
            <goals>
                <goal>generate</goal>
            </goals>
            <configuration>
                <inputSpec>
                    ${project.basedir}/src/main/resources/petstore.yml
                </inputSpec>
                <generatorName>spring</generatorName>
                <apiPackage>com.baeldung.openapi.api</apiPackage>
                <modelPackage>com.baeldung.openapi.model</modelPackage>
                <supportingFilesToGenerate>
                    ApiUtil.java
                </supportingFilesToGenerate>
                <configOptions>
                    <delegatePattern>true</delegatePattern>
                </configOptions>
            </configuration>
        </execution>
    </executions>
</plugin>

As we can see, we passed in the YAML file as inputSpec. After that, since we needed a Spring-based server, we used the generatorName as spring.

Then apiPackage specifies the package name where the API will be generated into.

Next, we have the modelPackage where the generator places the data models.

With delegatePattern set to true, we’re asking to create an interface that can be implemented as a customized @Service class.

Importantly, options for OpenAPI Generator are the same whether we’re using the CLI, Maven/Gradle Plugins, or online generation options.

3.2. Maven Dependencies

As we’ll be generating a Spring server, we also need its dependencies (Spring Boot Starter Web and Spring Data JPA) so that the generated code compiles and runs as expected:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>2.4.4</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.data</groupId>
        <artifactId>spring-data-jpa</artifactId>
        <version>2.4.6</version>
    </dependency>
</dependencies>

Apart from the above Spring dependencies, we’ll also need jackson-databind and springdoc dependencies so that our generated code compiles successfully:

<dependency>
    <groupId>org.openapitools</groupId>
    <artifactId>jackson-databind-nullable</artifactId>
    <version>0.2.1</version>
</dependency>
<dependency>
    <groupId>org.springdoc</groupId>
    <artifactId>springdoc-openapi-ui</artifactId>
    <version>1.7.0</version>
</dependency>

4. Code Generation

To generate the server stub, we simply need to run the following:

mvn clean install

As a result, here’s what we get:

Now let’s take a look at the code, starting with the contents of apiPackage.

First, we get an API interface called PetsApi that contains all the requests mappings as defined in the YAML specification.

Here’s the snippet:

@javax.annotation.Generated(value = "org.openapitools.codegen.languages.SpringCodegen", 
  date = "2021-03-22T23:26:32.308871+05:30[Asia/Kolkata]")
@Validated
@Api(value = "pets", description = "the pets API")
public interface PetsApi {
    /**
     * GET /pets : List all pets
     *
     * @param limit How many items to return at one time (max 100) (optional)
     * @return A paged array of pets (status code 200)
     *         or unexpected error (status code 200)
     */
    @ApiOperation(value = "List all pets", nickname = "listPets", notes = "", 
      response = Pet.class, responseContainer = "List", tags={ "pets", })
    @ApiResponses(value = { @ApiResponse(code = 200, message = "A paged array of pets", 
      response = Pet.class, responseContainer = "List"),
      @ApiResponse(code = 200, message = "unexpected error", response = Error.class) })
    @GetMapping(value = "/pets", produces = { "application/json" })
    default ResponseEntity<List<Pet>> listPets(@ApiParam(
      value = "How many items to return at one time (max 100)") 
      @Valid @RequestParam(value = "limit", required = false) Integer limit) {
        return getDelegate().listPets(limit);
    }

    // other generated methods
}

Second, since we’re using the delegate pattern, OpenAPI also generates a delegator interface for us called PetsApiDelegate.

In particular, methods declared in this interface return an HTTP status of 501 Not Implemented by default:

@javax.annotation.Generated(value = "org.openapitools.codegen.languages.SpringCodegen", 
  date = "2021-03-22T23:26:32.308871+05:30[Asia/Kolkata]")
public interface PetsApiDelegate {
    /**
     * GET /pets : List all pets
     *
     * @param limit How many items to return at one time (max 100) (optional)
     * @return A paged array of pets (status code 200)
     *         or unexpected error (status code 200)
     * @see PetsApi#listPets
     */
    default ResponseEntity<List<Pet>> listPets(Integer limit) {
        getRequest().ifPresent(request -> {
            for (MediaType mediaType: MediaType.parseMediaTypes(request.getHeader("Accept"))) {
                if (mediaType.isCompatibleWith(MediaType.valueOf("application/json"))) {
                    String exampleString = "{ \"name\" : \"name\", \"id\" : 0, \"tag\" : \"tag\" }";
                    ApiUtil.setExampleResponse(request, "application/json", exampleString);
                    break;
                }
            }
        });
        return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED);
    }

    // other generated method declarations
}

After that, we see there’s a PetsApiController class that simply wires in the delegator:

@javax.annotation.Generated(value = "org.openapitools.codegen.languages.SpringCodegen", 
  date = "2021-03-22T23:26:32.308871+05:30[Asia/Kolkata]")
@Controller
@RequestMapping("${openapi.swaggerPetstore.base-path:}")
public class PetsApiController implements PetsApi {

    private final PetsApiDelegate delegate;

    public PetsApiController(
      @org.springframework.beans.factory.annotation.Autowired(required = false) PetsApiDelegate delegate) {
        this.delegate = Optional.ofNullable(delegate).orElse(new PetsApiDelegate() {});
    }

    @Override
    public PetsApiDelegate getDelegate() {
        return delegate;
    }
}

In the modelPackage, a couple of data model POJOs called Error and Pet are generated, based on the schemas defined in our YAML input.

Let’s look at one of them — Pet:

@javax.annotation.Generated(value = "org.openapitools.codegen.languages.SpringCodegen", 
  date = "2021-03-22T23:26:32.308871+05:30[Asia/Kolkata]")
public class Pet {
  @JsonProperty("id")
  private Long id;

  @JsonProperty("name")
  private String name;

  @JsonProperty("tag")
  private String tag;

  // constructor

  @ApiModelProperty(required = true, value = "")
  @NotNull
  public Long getId() {
    return id;
  }

  // other getters and setters

  // equals, hashcode, and toString methods
}

5. Testing the Server

Now all that is required for the server stub to be functional as a server is to add an implementation of the delegator interface.

To keep things simple, we won’t do that here and instead only test the stub.

Moreover, before doing that, we’ll need a Spring Application:

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

5.1. Test Using curl

After starting up the application, we’ll simply run the command:

curl -I http://localhost:8080/pets/

And here’s the expected result:

HTTP/1.1 501 
Content-Length: 0
Date: Fri, 26 Mar 2021 17:29:25 GMT
Connection: close

5.2. Integration Tests

Alternatively, we can write a simple integration test for the same:

@RunWith(SpringRunner.class)
@SpringBootTest
@AutoConfigureMockMvc
public class OpenApiPetsIntegrationTest {
    private static final String PETS_PATH = "/pets/";

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void whenReadAll_thenStatusIsNotImplemented() throws Exception {
        this.mockMvc.perform(get(PETS_PATH)).andExpect(status().isNotImplemented());
    }

    @Test
    public void whenReadOne_thenStatusIsNotImplemented() throws Exception {
        this.mockMvc.perform(get(PETS_PATH + 1)).andExpect(status().isNotImplemented());
    }
}

6. Spring Boot Version 3.0 and the jakarta Namespace

Furthermore, our configuration works as expected for the Spring Boot project before version 3.0. However, starting from Spring Boot 3.0, the javax namespace is replaced with the jakarta namespace.

Hence, to generate a code compatible with Spring Boot 3.0 and later, we need to modify the configOptions option in our plugin configuration:

<configOptions>
     // ... 
    <useSpringBoot3>true</useSpringBoot3>
</configOptions>

Here, we added the useSpringBoot3 option and set it to true. This option enables the jakarta namespace by default.

Alternatively, we can specify useJakartaEe option in the configOptions:

<configOptions>
     // ...
    <useJakartaEe>true</useJakartaEe>
</configOptions>

By setting the useJakartaEe option to true, the generated code uses the jakarta namespace and compiles without error.

Notably, defining both options in a Spring Boot 3.0 project is redundant because the useSpringBoot3 option enables the useJakartaEe option by default.

7. Conclusion

In this article, we saw how to generate a Spring-based server stub from a YAML specification using the OpenAPI generator’s Maven plugin.

As a next step, we can also use it to generate a client.