|
2 | 2 |
|
3 | 3 | This project contains an opinionated library and SBT Plugin for Scala code generation from [OpenAPI 3.0](https://swagger.io/specification/) compliant YAML.
|
4 | 4 |
|
5 |
| -This will generate Components (i.e., schemas or types), and Paths (i.e., route definitions) for REST APIs. |
| 5 | +This will generate data structures(i.e., schemas or types), Circe JSON serializers, and Paths (i.e., route definitions) for REST APIs. |
6 | 6 |
|
7 | 7 | We do not support all OpenAPI 3.0 features. For more details on what is supported, look at the [Limitations](#limitations) section.
|
8 | 8 |
|
9 |
| -### OpenAPI Scala |
| 9 | +## Modules |
10 | 10 |
|
11 |
| -SBT sub-project `openapi-scala` contains the main logic and library for loading, representing, and translating YAML to Scala code. |
12 |
| -These contain components that are translated into Scala's `case classes` and Routes, which are explained in the next section. |
| 11 | +### sbt-openapi |
| 12 | +The SBT module `sbt-openapi` is the interface for the generator toolchain and contains: |
| 13 | +a) an interface to easily add the openAPI generator to a project |
| 14 | +b) Put external openAPI resources/definitions/yaml-files next to internal definitions to make them referable. This enables |
| 15 | +sharing artifact across multiple openAPI projects (like shared error messages/ data structures). |
| 16 | +c) logic to load, resolve and aggregate openAPI definitions using the io.swagger.parser and generated a single combined |
| 17 | + openapi.json definition as output |
| 18 | +d) trigger code generation. (`openapi-scala`) |
| 19 | + |
| 20 | +### openapi-scala |
| 21 | +`openapi-scala`s main responsibility is to parse a single openAPI.json file into memory (`ast`), transform it into a |
| 22 | +generator friendly intermediate representation (`repr`) and generate scala code (`generator`). |
| 23 | + |
| 24 | +### openapi-lib & openapi-htt4s-lib |
| 25 | +Libraries used by the generated code. |
13 | 26 |
|
14 | 27 | #### Routes
|
15 | 28 |
|
16 |
| -We support different types of Route generation, depending on the backend you need it for. |
| 29 | +We support different types of Route generation, depending on the backend you need it for. //TODO which backends do we have and how do we configure it? |
17 | 30 |
|
18 | 31 | - The generic Routes are each translated to a Scala `trait` declaring interfaces for that particular HTTP route.
|
19 |
| -- The http4s Routes translate into two files, one file with a trait for the implementation you'll need to provide and one file with an object apply function of which accepts mentioned implementation trait. |
20 |
| - |
21 |
| -The names of the functions and values for the routes is generated at run-time. However, if an `operationId` field is defined (as specified in OAS 3.0) we will use those to generate user-friendly function names. |
| 32 | +- The http4s Routes translate into two files, one file with a trait for the implementation you'll need to provide and |
| 33 | +one file with an object apply function of which accepts mentioned implementation trait. |
22 | 34 |
|
| 35 | +The names of the functions implementing the route are either |
| 36 | + a) the concatenation of http method and path or |
| 37 | + b) the optionally more descriptive content of the `operationId` field (as specified in OAS 3.0) |
| 38 | + |
23 | 39 | ## Components
|
24 | 40 |
|
25 |
| -Components in OpenAPI are the types that can be referred to as inputs/outputs for routes. A common use of components is to define product types. We take these components and translate them to Scala case classes. Consider the following example: |
| 41 | +Components in OpenAPI are the types that can be referred to as inputs/outputs for routes. A common use of components is |
| 42 | +to define product types. We take these components and translate them to Scala case classes. Consider the following example: |
26 | 43 |
|
27 | 44 | ```yaml
|
28 | 45 | components:
|
@@ -75,6 +92,7 @@ libraryDependencies += "com.enfore" %% "openapi-lib" % "<openapi-scala-version>"
|
75 | 92 |
|
76 | 93 | Additionally, you will need to satisfy these library dependencies for `openapi-lib`. The provided versions are tested and made sure to work. You should be able to use any version compatible with your project though.
|
77 | 94 |
|
| 95 | +// TODO shouldn't we automatically add these dependencies via the SBT auto plugin via flag? |
78 | 96 | ```scala
|
79 | 97 | "com.beachape" %% "enumeratum" % "1.5.13",
|
80 | 98 | "com.beachape" %% "enumeratum-circe" % "1.5.20",
|
|
0 commit comments