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

Add support for service groups #24

Closed
kop opened this issue Nov 25, 2016 · 1 comment
Closed

Add support for service groups #24

kop opened this issue Nov 25, 2016 · 1 comment

Comments

@kop
Copy link

kop commented Nov 25, 2016

Steps to reproduce

I'm building an API with a lot of exposed services that belong to different groups.
For example, I have a group prospecting, with 8 different services inside it. What I want to achieve is URI structure like "prospects/persons/{id}", "prospects/companies/{id}" and so on.

To archive that, I'm defining my services like so:

  app.use('/prospects/persons', Object.assign(memory(), {docs}));

It works: API endpoints are available and SwaggerUI shows all endpoints.
But there are some serious problems.

Expected behaviour

What I want to do is to define docs for every of my sub-services and see them in Swagger. Also, ideally, I would like them to be displayed as different groups in SwaggerUI.

Actual behaviour

When I do so, they all appear under same tag "prospects" - this means that I can't set definitions for them (every definition is replacing the previous one) and can't group them by actual service name.

The problem is here because of automatic tags generation. It would be great to have an ability to:

  • set custom tags for service;
  • or at least support nested routes during generation.

System configuration

Module versions:

  • feathers@2.0.2;
  • feathers-swagger@0.3.1;
@kop
Copy link
Author

kop commented Nov 25, 2016

I've realised now that I can overcome definitions problem with using definitions field instead of definition. But there is still a problem with grouping by different tag.

P.S. I will be happy to fill a PR, but would like to discuss implementation before.

Maybe it makes sense to add a couple of recognised fields in docs schema?

  1. tags (optional) - array of tags to assign to the service. If not given, current generation rules will apply.
  2. definitionName (optional) - name to assign to definition. If not given, the first value from the array of tags will be used.

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

No branches or pull requests

1 participant