Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/bonitasoft/bonita-openapi

This repository contains the Bonita OpenAPI specification
https://github.com/bonitasoft/bonita-openapi

api bonita delivery-github-release hacktoberfest http lifecycle-independent openapi published-never rest-api

Last synced: about 4 hours ago
JSON representation

This repository contains the Bonita OpenAPI specification

Awesome Lists containing this project

README 

        
= Bonita OpenAPI specification



image:https://github.com/bonitasoft/bonita-openapi/workflows/build/badge.svg[Actions Status, link=https://github.com/bonitasoft/bonita-openapi/actions?query=build]

image:https://img.shields.io/github/v/release/bonitasoft/bonita-openapi?color=blue&label=Release[GitHub release, link=https://github.com/bonitasoft/bonita-openapi/releases]

image:https://img.shields.io/badge/License-GPL%20v2-blue.svg[GPLv2 License, link=LICENSE]



This project is about describing the Bonita web API in https://swagger.io/specification/[Open API v3] format.



This single yaml file is to become the single source of truth for the Bonita features accessible through HTTP.



Based on this file, one could generate : documentation, client in different language and/or technology, server side stubs, ...



== Open API v3



The specification file is written in `yaml` format because multiline support is much better than in `json`

The specification has a lot of _description block_ and since it is a _documentation_, it needs to be quite verbose.



The specification file can be found here: `openapi/openapi.yaml`



We make use of https://swagger.io/docs/specification/openapi-extensions/[extensions] to add better support for some documentation sites (x-logo, x-codeSamples, ...)



This repository structure was inspired by https://github.com/Redocly/create-openapi-repo.



== Live Documentation



The api descriptor file can be used to render documentation sites. Those sites have different rendering and may show different parts of the specification file.

That's the reason why it is interesting to test and evaluate different sites and rendering.



You 'll need to install the https://github.com/redocly/openapi-cli[openapi-cli] to be able to work on the specification.



=== Redoc Preview



A https://github.com/Redocly/redoc[ReDoc] site is available at http://localhost:8080 when you run from project directory



[source,bash]

----

npm start

----



This preview is the preferred one when editing the specification.



=== Swagger Preview



The `docker-compose.yaml` file at the project root starts two sites: a https://swagger.io/tools/swagger-ui/[swagger-ui] site and a Bonita instance to query



To start the container, just issue the following comment at the project root:



[source,bash]

----

docker-compose up -d

----



You should be able to access:



- Bonita: http://bonita.localhost/bonita

- Swagger UI: http://swagger.localhost



NOTE: You can keep on editing the specification file and just refresh the browser to see the changes.



== Links



*Open API documentation:*



https://swagger.io/docs/specification/basic-structure/



*IDE support:*



- intellij: https://www.jetbrains.com/help/idea/openapi.html

- eclipse: https://marketplace.eclipse.org/category/free-tagging/openapi



*Specification samples:*



- Docker API: https://docs.docker.com/engine/api/v1.40/

- Discourse API: https://docs.discourse.org/

- API hub: https://apis.guru/browse-apis/

- Samples: https://github.com/OAI/OpenAPI-Specification/tree/master/examples/v3.0



*ReDoc*



- https://github.com/Redocly/redoc



== Create a release



A GitHub action is used to automate the link:.github/workflows/release.yml[release workflow].

The workflow is triggered by user action and you need to choose the release type (following semver).



:NOTE: This action will automatically update the version (field `version` in `package.json`,`package-lock.json` and `openapi.yaml`)



A GitHub release is created with the `yaml` specification file, the `json` postman collection and the static documentation zip attached.

Release note must be filled manually.



:TIP: You can edit the latest release description and click on `Generate releases notes` button to help you to generate a description including the changelog.



NOTE: Use `patch` release if the release content don't include any breaking changes



== After a release



To deploy your newest release on the documentation site, you need to:



* On https://github.com/bonitasoft/bonita-rest-documentation-site/blob/master/cli/restdoc-site.cfg.json[rest documentation config], add the released version for each compatible Bonita version.

* Open a PR and asked for a review.

* Follow updates on your PR, and also to update `openApiLatestVersion:` in `antora.yml` file for each https://github.com/bonitasoft/bonita-doc/[Bonita documentation content] corresponding branches.



== How to contribute



We would love you to contribute, pull requests are welcome!

Have a look to link:DEV.md[] guidelines and don't forget to sign our Contributor Licensing Agreements when opening a pull request.

This repository uses https://guides.github.com/introduction/flow/[Github flow], so pull requests should target the `master` branch.



When you open a pull request, keep in mind to add labels to help the release-note content writing automatically. Labels available are :



|===

|Release note section| Github PR label

|New Features 🎉| enhancement

|Bug fixes 🛠| bug

|Other Changes| *

|===



:INFO: If you don't want to see your PR in the release-note, you need to add one of this labels: `dependencies`, `github_actions` or `ignore-for-release-notes`.