Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As you can see in the diagram above also so called bean parameters are supported. Bean parameters can be used for REST services to group a set of parameters together e.g. you always have the same context parameters that are supported on requests.

Image Added

Final step is to also connect your REST services with the specification. To do so you need to define a dependency between your Open API Specification and your REST service.

How to modularize Open API Specifications

As soon as you will start to work with Open API on a more complex scenario you will find out that the YAML files will become rather big and confusing. Of course you still have your UML model where you have a way better overview. However also from the life cycle perspective it might be a good idea to split a large specification into smaller independent pieces.

...

Open API does not define an explicit concept of modules or anything like that but it allows to reference on elements that are located in another Open API Specification. And this is exactly the way how we can modularize our specs. Instead of defining one large Open API Specification in the UML model we define multiple of them and them link them together using dependencies with stereotype «OpenAPISpecReference».

As you can see in the diagram directly above Open API Specification Product Services has a dependency on Product Base Definitions. This means that all types from Product Base Definitions can also be used in Product Services. By default it is assumed that the referenced specification is located in the same directory as the other one. However it it also supported to define an URL for the referenced specification.

When you define dependencies between Open API Specifications please ensure that all of them support Semantic Versioning otherwise changes dependent specification might make your API incompatible to previous versions

Please also refer to:

...