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

Feature: sub-tags grouping #1367

Open
kamil-kielczewski opened this issue Oct 5, 2017 · 6 comments

Comments

Projects
None yet
7 participants
@kamil-kielczewski
Copy link

commented Oct 5, 2017

I don't know it is good place to introduce new Feature into swagger specification - if not please give me information where i can put this proposition.

My proposition is to use following convention in tags names (using dots to nesting subtags):

users.client     # and use this tag to client GET/POST/...
users.seller     # and use this tag to seller GET/POST/...
users.admin      # and use this tag to admin GET/POST/...
books            # use this to general books GET/POST...
books.sell       # use this to GET/POST... associated with the sell
books.management # use this to GET/POST... associated with the books management

And in output generated documentation web-page we will get:

user >
       client >
GET
POST
...
       seller >
GET
POST
...
       admin >
GET
POST
...

books >
GET
POST
...
       sell >
GET
POST
...
       management >
GET
POST
...

This feature is especially practical for large APIs.

Or may be better way is not change 'tags' but rather add new filed 'groups' which will contain such dot-separated nested groups?

@ymohdriz

This comment has been minimized.

Copy link

commented Mar 15, 2018

Hi @kamil-kielczewski

Adding the path level tagging solves the requirement, if I understood correctly.
I have raised a PR #1509 for the same.

Thanks,
Mohammed

@maaland

This comment has been minimized.

Copy link

commented Jul 30, 2018

I support the request for a sub-tags. I want to be able to group (or at least sort) the methods under each of my endpoints, and as far as I can tell, that's not possible right now.

@jukeblimp32

This comment has been minimized.

Copy link

commented Sep 18, 2018

I support the request for sub-tags. Right now my tags are my collections. But with some collections exposing several different resources that can each support GET, PUT, and PATCH, the tags can become very cluttered. I want to be able have sub-tags for each resource within the collection tag.

@farmbotgianpaolo

This comment has been minimized.

Copy link

commented Nov 29, 2018

I support the request for sub-tags. I have a big API with tens of access points that need categories.

@anentropic

This comment has been minimized.

Copy link

commented Apr 8, 2019

This is one area where apib is better... there is a hierarchy like "Resource Group > Resource > Transition" where a Transition is roughly an OAS path and a Resource could be represented with an OAS tag.

For large APIs it would be useful to be able to group the endpoints at a level above single tags.

OAS is flexible enough I can represent this in the data with some combination of tags and extension properties, but for it to really be useful you would want a standardised representation that the tools such as Swagger UI then also support.

@teohhanhui teohhanhui referenced this issue Apr 10, 2019

Open

[RFC] Subresource metadata #2706

0 of 4 tasks complete
@amandajordaan

This comment has been minimized.

Copy link

commented Jun 3, 2019

I have a very large API to document, large with a very basic structure:
API {
Service 1 {
Tool 1,
Tool 2,
Tool 3, (etc)
}
Service 2 (etc) {
Tool 1,
Tool 2,
Tool 3, (etc)
}
...
}
Being able to link one path to two tags and having them fall in a parent-child structure, would solve this problem. I have played around with the entire spec and it simply won't stretch to accommodate this API. Has this need been addressed yet? I find a great number of people needing this, but no answers on how to accomplish this yet - has anyone found a work-around on this limitation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.