Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create Camara-OAS-Sections-Guidelines.md #317

Draft
wants to merge 10 commits into
base: main
Choose a base branch
from
108 changes: 108 additions & 0 deletions documentation/Camara-OAS-Sections-Guidelines.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@
# CAMARA OAS Sections Guidelines

## Table of Contents

* [Introduction](#introduction)
* [Conventions](#conventions)
* [OAS Sections](#oas-sections)
+ [OpenAPI Version](#version)
+ [Info Object](#info-object)
+ [Title](#title)
+ [Description](#description)
+ [Version](#version)
+ [Terms of service](#tos)
+ [Contact information](#contact)
+ [License](#license)
+ [Extension field](#ext-field)
+ [Servers](#servers)
+ [Paths](#paths)
+ [Components](#components)
+ [Schemas ](#schemes)
+ [Responses](#responses)
+ [Parameters](#parameters)
+ [Request bodies](#req-bodies)
+ [Headers](#headers)
+ [Security schemes](#sec-schemes)
+ [Security](#security)
+ [Tags](#tags)
+ [External Documentation](#ext-doc)

## Introduction
Camara uses OpenAPI Specification (OAS) to describe its APIs. The below guidelines specify the restrictions or conventions to be followed within the OAS yaml by all Camara APIs (referred below simply as APIs).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Camara -> CAMARA (multiple occurences)


## Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest to add a section on the OAS file name which should be the api name in kebab-case.yaml e.g. simple-edge-discovery.yaml

## OAS Sections

### OpenAPI Version
APIs shall use the OAS version 3.0.3.

### Info Object
An example of the info object is shown below:
```
info:
title: Number Verification
description: |
This API allows to verify that the provided mobile phone number is the one used in the device. It
verifies that the user is using a device with the same mobile phone number as it is declared.
version: 1.0.1
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
x-camara-commonalities: 0.4.0

```
#### Title
Title describes the API shortly. The title shall not include the term "API" in it.

#### Description
No special restrictions specified in Camara.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the description shall include the user documentation for the API.
as well as a copy from the section from the ICM guidelines on the auth flows applicable to the API.


#### Version
APIs shall use the [versioning-format](https://lf-camaraproject.atlassian.net/wiki/x/3yLe) as specified by the release management working group.

#### Terms of service
Terms of service shall not be included. API providers may add this content when documenting their APIs.

#### Contact information
Contact information shall not be included. API providers may add this content when documenting their APIs.

#### License
The license object shall include the following fields:
```
license
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
```

#### Extension field
The API shall specify the commonalities release number they are compliant to, by including the x-camara-commonalities extension field.

### Servers
The servers object shall have the following content:
```
servers:
- url: {apiRoot}/<api-name>/<api-version>
variables:
apiRoot:
default: http://localhost:9091
description: API root, defined by the service provider, e.g. `api.example.com` or `api.example.com/somepath`
```
<b>API-Name</b>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use as in the example above ?

API-Name is what is specified as the base path, prior to the API version, in the servers[*].url property. If more than one server object instances are listed, each servers[*].url property must have the same string for the API name and version in respective instance

For the below example, the API-name would be location-verification.
```
/location-verification/v0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make this example use v1 instead of v0 (see next comment)

```

</br>

<b>API-Version </b> </br>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use as in the example above ?


API-Version shall be same as the [Version](#version) in the info object.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shall be a "v" concatenated with the MAJOR version number of the version field in the info object.
A CAMARA specific exception is that for APIs with version 0.y.z, the both the MAJOR and the MINOR version number are included in the , e.g. simple-edge-discovery/v0.3

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should probably reference the section on API versioning in the API design guidelines


### Paths
No special restrictions or changes specified in Camara.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this be added to the end of the API Guidelines where there is a section on the OAS specification ? else this risks to create duplication / divergence