Download the PHP package jeandormehl/openapi-gen without Composer

OpenApi Generator for Laravel, Lumen and Dingo.

About

The openapi-gen package provides a convenient way to create OpenApi specifications for Laravel, Lumen or Dingo using a single configuration file. It is aimed at lightweight microservices and can be parsed by various packages to enable functionality such as gateway and relay routing.

The idea came from the lack of such packages and to stay away from polluting Controllers, Models and such with millions of lines of annotations. Annotations also lack the ability to use variables as values.

This package uses cebe/php-openapi for most of the heavy lifting, including validation of the specification. Thanks for the great package!

Table of Contents

• Features
• Installation
  • Laravel
  • Lumen
  • Dingo
• Configuration
  • Route
  • Yaml
  • OpenApi
  • Info
  • Servers
  • Security
  • Tags
  • ExternalDocs
  • Components
  • Schemas
  • Responses
  • Parameters
  • RequestBodies
  • Headers
  • SecuritySchemes
  • Paths
• Todo
• License

Features

• Auto generate basic schema definitions from model classes.
• Auto generate common HTTP responses used by most REST API's.
• Entire specification is stored nicely and neatly in one configuration file.
• Create any OpenApi object using simple arrays.

Installation

Require jeandormehl/openapi-gen package in your composer.json and update your dependencies:

Laravel

Add Rapid\OAS\Providers\ServiceProvider to your config/app.php providers array.

Publish the minimum configuration:

Note: Package autodiscovery is not used because Dingo uses a different service provider to Laravel/Lumen. Will find a way to combine them all into one provider at some point.

Lumen

Copy the config file:

Load the configuration into bootstrap/app.php:

Register the service provider:

Dingo

Follow the instructions for either Laravel or Lumen, depending on what you're using.

When registering the service provider, replace with Rapid\OAS\Providers\DingoServiceProvider::class

Note: When using Dingo, your API_PREFIX will be prepended to the route that is registered.

Configuration

The oas.php file contains your entire specification and depending on its contents, the specification will be generated. Basic validation is also provided so if you make a mistake in your config file, the package should give you an idea of where and how to correct the issue.

The file consists of arrays matching the OpenApi specification. When I created this package, OpenApi was currently on version 3.0.2.

Here are useful links to ensure validity of your configuration:

• OpenAPI Specification on Github
• OpenAPI Map

route

The route key controls the route that is registered to access the specification. Here you enable/disable the route, set the path and prefix and add middleware if necessary.

Note: When using Dingo, your API_PREFIX will be prepended to the route that is registered.

yaml

The yaml key defines the path to output the specification as a .yml file. By default, the file is placed in storage/app/oas.yml. To generate the yaml file, run the following artisan command:

openapi

The openapi key specifies the OAS version. This defaults to 3.0.2.

Please see the oasObject for more information.

info

The info key represent an OAS info object.

Minimum configuration:

Full configuration:

Please see the infoObject for more information.

servers

The servers key contains arrays of OAS server objects.

Mimimum configuration:

Full configuration:

Please see the serverObject and serverVariableObject for more information.

security

The security key defines security requirement objects. The name used for each property MUST correspond to a securityScheme declared in the securitySchemes under the components object. These are required globally for use of the API. If the security scheme is of type oauth2 or openIdConnect, then the value is a list of scope names required for the execution. For other security scheme types, the array MUST be empty.

Minimum configuration:

Full configuration:

Please see the securityRequirementObject for more information.

tags

The tags key contains arrays of OAS tag objects.

Minimum configuration:

Full configuration:

Please see the tagObject for more information.

externalDocs

The externalDocs key contains the external documentation OAS object.

Minimum configuration:

Full configuration:

Please see the externalDocumentationObject for more information.

components

The components key. Refer to componentsObject.

Schemas

The schemas key. Refer to schemaObject.

Auto generated model schemas.

This packages allows you to automatically generate basic schemas based on your Eloquent models. Providing an array of Fully Qualified Class Names (FQCN) inside a models array, the package will attempt to create the schemas for you which can later be referenced in other keys.

Note: Currently supports MySQL, SQLite, PostgreSQL and Oracle.

Note: These schema definitions are very basic, containing only the following values:

• Title
• Description
• Required
• Properties

Properties will only contain the following attributes:

• Description
• Type
• Format
• Nullable
• Default

Properties defined inside the models hidden array and inside the configuration hidden tag will be excluded from the schema.

Minimum configuration:

Full configuration:

Standard schema objects

The schemas key represent an array of OAS schema objects. Here you can define your custom schemas and reference them later in your configuration. It is highly recommended to define all your schemas here and simply reference them in the configuration as opposed to creating inline schemas, although the functionality does exist.

Example Enum schema:

Example Object schema:

Note: The schema OAS object contains many properties depending on the type of schema definition you are using.

Refer to schemaObject for all additional properties and types.

Responses

Auto generated common HTTP responses

The responses key contains a key called statusCodes which defines common HTTP responses used in almost all REST APIs. This key is simply an array of HTTP status codes which will generate the responses. At this time, all the responses generated are application/json and can be referenced anywhere in your specification.

Note: Do not define a 200 OK response here unless that is all you wish to return to services consuming your API. 200 responses should generally be defined within paths or operations using schema and requestBodies $refs.

Configuration:

Standard response objects

The responses key represent an array of OAS response objects. Here you can define your custom responses and reference them later in your configuration. It is highly recommended to define all your responses here and simply reference them in the configuration as opposed to creating inline responses, although the functionality does exist.

Configuration:

Parameters

The parameters key is used to specify parameters and can be referenced anywhere in your specification. It is highly recommended that you define all parameters in this key and reference them throughout your specification.

Configuration:

Please refer to parameterObject for more information.

RequestBodies

The requestBodies key represent an array of OAS requestBody objects. Its is recommended that all requestBodies are defined and simply referenced where needed within the specification.

Configuration:

Headers

The headers key represent an array of OAS header objects. Its is recommended that all headers are defined and simply referenced where needed within the specification.

Minimum configuration:

Full configuration:

Please refer to the headerObject and the mediaTypeObject for more info on how these are created.

SecuritySchemes

The securityScheme key. These link directly to the security key and should be defined before being using in the security or operation objects.

Full configuration:

Please refer to securitySchemeObject, oauthFlowsObject and oauthFlowObject for more details.

paths

The paths key. Refer to pathsObject.

This is the most important key of the entire configuration. This will define your paths and operations. Where possible, try to only use $refs and keep this configuration as clean and neat as possible.

TODO

• Add examples objects to specification. See exampleObject.
• Add links objects to specification. See linkObject.
• Add callbacks objects to specification. See callbackObject.

License

Released under the Apache-2.0 License, see LICENSE.