teamdigitale / openapi Goto Github PK

View Code? Open in Web Editor NEW

1.0 5.0 4.0 82 KB

OpenAPI Schema and Resources

Home Page: https://teamdigitale.github.io/openapi/

Python 68.21% Makefile 31.79%

openapi's Introduction

OpenAPI v3 schemas

This repo contains useful and reusable schemas to implement REST APIs distributed via github pages.

Getting the specs

Latest master is available at:

https://teamdigitale.github.io/openapi/master/definitions.yaml

Tagged specs are here:

https://teamdigitale.github.io/openapi/0.0.7/definitions.yaml

Specs are assebled from the following directories:

docs/
├── headers             # HTTP Headers
├── parameters          # HTTP query parameters
├── responses           # Responses
└── schemas             # Various schema files
    ├── money.yaml
    ├── ...
    └── problem.yaml

Building the specs

Every commit is tested via the tox python framework.

master and tags trigger make ghpages which:

generates definitions.yaml
push it to gh-pages branch, under $tag/definitions.yaml

openapi's People

Contributors

Stargazers

Watchers

Forkers

xmomix poldinik nnzjd simonepadovan

openapi's Issues

I expect

To have location header

I expect

no v2
definitions can be tagged
references should be maintained and resolved properly
version should be consistent across all files

Problem json should not expose implementation details.

I expect

Problem json not to espose implementation details.

Instead

The Problem example does, with database connection timeout

HTTP_STATUS_CODE: 204 and 500

hi all

In our (INGV) internal definitions, we've defined 500InternalServerError and 204NoContent responses:

https://github.com/INGV/openapi/blob/master/docs/definitions.yaml#L314

Could be a good idea to add It here?

https://github.com/teamdigitale/openapi/blob/master/docs/responses/v3.yaml

Add OAS3 metadata to definitions.yaml

Buongiorno @ioggstream

In alcune API che sto scrivendo, sto "referenziando" le vostre; ad esempio:

$ref: 'https://teamdigitale.github.io/openapi/0.0.7/definitions.yaml#/schemas/Latitude'

tutto funziona alla perfezione e anche la validazione dello YAML viene eseguita senza problemi.

Il problema si presenta quando, dallo Swagger Editor o dal SwaggerHub, provo a generare le classi per creare un Client; o piu' semplicemente quando, sempre da SwaggerHub, chiedo di esportarmi lo "YAML Resolved" cioè con la risoluzione di tutte le referenze esterne. Facendo queste operazioni ottengo un errore di:

Error.Cannot parse invalid API definition, please fix any syntax issues

Ho aperto un Ticket con lo "SmartBear Customer Care" e questa e' la loro risposta:

From: SmartBear Customer Care <[email protected]>
Subject: Case #00490372: SwaggerHub chat from [email protected] on 09/15/2021 08:02 GMT
Date: 17 September 2021 at 17:28:29 CEST
To: "[email protected]" <[email protected]>

Hi Valentino,

This message is a follow-up to our recent chat regarding some issues when downloading a resolved version of the Dante Web Services specification.

Most likely, the issues are caused by external references specified in the documentation, like this one:
$ref: 'https://ingv.github.io/openapi/definitions.yaml#/parameters/starttime'

and by external references specified in the referenced definitions.yaml file itself, like this one:
$ref: 'https://teamdigitale.github.io/openapi/0.0.7/definitions.yaml#/schemas/Latitude'

Both definitions.yaml files are not valid specification or domain files. They have a structure similar to a common specification or a domain, but they still miss some important fields like the root openapi object, the components object, and so on, so cannot be parsed properly. Please adjust referenced files according to the OAS format requirements and try to download the specification afterward. Does it make any difference?

Please refer to the following help topic for details on the specification and domain structure:
https://swagger.io/docs/specification/basic-structure/
https://support.smartbear.com/swaggerhub/docs/domains/oas3-domain-example.html

Regards,
Julia Kolosova
Customer Care Engineer

Forse questi file di definitions.yaml esterni vanno comunque scritti rispettando tutte le specifiche OpenAPI e devono essi stessi passare la validazione?

Inizierò in settimana a modificare il nostro:

https://ingv.github.io/openapi/definitions.yaml

e vedo se il problema e' questo.

Add json counterpart

I expect

To have both yaml and json

constraint fields length

I expect

to constraint fields length

Conform Money to OpenBanking best practices

I expect

to conform Money to the Open Banking best practices.

Add OAS metadata to definition file.

I expect

the definition file to have oas metadata

cc: @vlauciani

Some useful headers

Header	Rationale
Cache-Control: no-store	Prevent sensitive information from being cached.
Content-Security-Policy: frame-ancestors 'none'	To protect against drag-and-drop style clickjacking attacks.
Content-Type	To specify the content type of the response. This should be application/json for JSON responses.
Strict-Transport-Security	To require connections over HTTPS and to protect against spoofed certificates.
X-Content-Type-Options: nosniff	To prevent browsers from performing MIME sniffing, and

teamdigitale / openapi Goto Github PK

openapi's Introduction

OpenAPI v3 schemas

Getting the specs

Building the specs

openapi's People

Contributors

Stargazers

Watchers

Forkers

openapi's Issues

I expect

I expect

I expect

Instead

I expect

I expect

I expect

I expect

Recommend Projects

Recommend Topics

Recommend Org