Export filtered APIs with specified tags or other ways

[oreo0725]

Is your feature request related to a problem? Please describe.
Sometime we have to only export partial APIs to generate the document for external partners.
For example,
I have 2 APIs /user/new and /internal/user/new in users_resource.go

• Only the /user/new I wanna export it to a swagger-public.yaml
• Both /user/new and internal/user/new should be exported to another swagger.yaml

Describe the solution you'd like
Is that possible to have a --exclude-tags or --include-tag options for the generator function?
or just a whole new annotation to fullfil this requirement

Describe alternatives you've considered
Use @Tags may not be a good choice because it will create a new layout group for HTML generated by such swagger-codegen

[ubogdan]

@oreo0725 you may need to figure out a workaround since swagger doesn't not support this and I don't see it implemented. Since you have 2 APIs , you may use to create 2 endopints http://api.domain.com and http://internal-api.domain com or you can have different roots line /api/new and /internal/new .

[oreo0725]

@ubogdan,
Perhaps my explanation is not that clear.
What I really want is like the --exclude argument implementation, not only for the file/dir level but for the API/function level

[ubogdan]

@oreo0725 This is an Open Source project. Please feel free and contribute via PR and we will be more than welcome to add this feature.

[igorkova]

@oreo0725 Do you plan on creating PR from your forked branch?

[johan-lejdung]

I'm in the same boat. We have a monorepo with both internal and public API's, using the exclude flag doesn't really work at all times (depending on how you've created your package structure).

It seems avyfinans#1 added the ability to parse by extension (awesome addition!):

---

Add comment tag like
// @x-public true

on cli use swag init --parseExtension public

result will be that only those operations with @x-public true will be saved to the swagger definition

---

The new feature isn't merged here yet though, #1219 @igorkova what do you have left to do on it? Anything we can help with @ubogdan?

[ubogdan]

As the contributor mentioned

igorkova commented on Jun 2
This is not 100% ready yet. Let us get back

[igorkova]

Ok. We are back on this one.

I see that in the meantime we got something similar in #1379, however, that doesn't solve the use-case we have.

The main reason it doesn't work is that we would need to be able to expose only some endpoints from a certain Tag (imagine we have a tag called User and all user related CRUD endpoints are there, but we want to expose only GET endpoint).

We can't use User as a tag to filter on because we will expose more than we want. Solution according to #1379 is maybe to introduce another tag called Expose_this (Then we have a line like // @Tags User, Expose_this, however, then openAPI spec becomes strange and we will get the same endpoint rendered twice, under 2 OpenAPI tag sections (User and Expose_this)

@Trial97 Is there a way to achieve what we need with #1379 (maybe something we are missing to understand there)

Also, maybe @ubogdan and @sdghchj have ideas?

[ubogdan]

I believe this has to be done via go-build tags.

[oreo0725]

@igorkova , forgive my late reply
I think this commit in my fork previously is just a hack to meet some requirement that day.

I totally agree with your design in #1219 . Looking forward to see the merge

[igorkova]

@oreo0725 I believe you had much better approach of filtering out operations even before they are parsed (your matchTags method).
We've been letting the processing go through and we would filter it out later on.

We've made now matchExtension which is inspired by your matchTags. The credit goes to you for that part! 🙌

Looks like workflow is green since today so now we'll just wait for some reviews as soon as maintainers get some time.

[oreo0725]

solved by #1219, close

Thanks @igorkova