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

Support tags in OpenAPI Object #75

Open
kylef opened this issue Nov 27, 2018 · 5 comments
Open

Support tags in OpenAPI Object #75

kylef opened this issue Nov 27, 2018 · 5 comments
Labels

Comments

@kylef
Copy link
Member

kylef commented Nov 27, 2018

This likely requires design in API Elements specification and designing how to expose this information in API Elements.

@kylef kylef transferred this issue from another repository Jan 18, 2019
@kylef kylef added the openapi3 label Jan 18, 2019
@pksunkara pksunkara added this to To do in OAS 3 MVP Feb 12, 2019
@galcohen92
Copy link

galcohen92 commented Mar 5, 2019

I would like to work on this issue, but I need more info about api-elements's structure, where is each field mapped to?
I found this docs but it only explain the general structure not a specific mappings, for example where its written that info.title mapped to parseResult.api.title?

@kylef kylef removed this from To do in OAS 3 MVP Mar 5, 2019
@kylef
Copy link
Member Author

kylef commented Mar 5, 2019

Hi @galcohen92, this field cannot currently be mapped to API Elements, the intermediate form of API Description formats and Apiary. The first step in this task is proposing a concept of tagging, or classifications to API Elements. Once that design is agreed upon then it would be a matter of updating API Elements specification (releasing API Elements 1.1 or such with all other changes needed for other OAS 3 features), this must not be a breaking change. We would then need to implement the functionality in the OAS 3 (and OAS 2) parser. Then tools such as Apiary Documentation, Dredd etc would need to be updated to make use of these classifiers.

As this adapter is still in early stages, our first focus is to implement all of the functionality from OpenAPI 3 that we can already describe in the current version of API Elements 1.0 for version 1 of our adapter. Once that is done we would then go over unsupported functionality and introduce these concepts into API Elements and our subseqent tooling.


  • Design how we can represent a classifications (or tags) system in API Elements. I think we should think about the concept and figure out how it can best fit into API Elements. We should do research into how other API Descriptions make use of classifications. We want to avoid designing API Element features specifically around a single API Description format and instead a design a cannonical format that fits.
  • Update API Elements Specification
  • Implement in OAS 3 Parser (and minim-api-description)
  • Implement in OAS 2 Parser
  • Schedule implementations in other products making use of API Elements
    • Dredd
    • ApiaryUI (Documentation)
    • Apiary Styleguides / Constitutions

@fscorro
Copy link

fscorro commented Jun 10, 2020

Hi @kylef, is there any update about this issue?

@tylermilner
Copy link

I'll be following this. I created an API in Postman using openapi 3.0 format and, following the auto-generated sample spec, added tags properties to my requests. I got tired of writing the spec inside of Postman so I copy/pasted it to Apiary and a bunch of 'Operation Object' contains unsupported key 'tags' semantic issues popped up. I guess Apiary doesn't fully support the openapi 3.0 spec? I see information about using tags in the Swagger openapi documentation.

@KlausGrosser
Copy link

Any progress? With all of these unsupported stuff it is almost impossible to parse successfully

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants