Allow specifying custom tags at the route level #523
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
edd12e9 to
9340714
Compare
kzaitsev
reviewed
Oct 21, 2016
| @@ -4,7 +4,7 @@ | |||
|
|
|||
| * [#520](https://github.com/ruby-grape/grape-swagger/pull/520): Response model can have required attributes - [@WojciechKo](https://github.com/WojciechKo). | |||
| * [#510](https://github.com/ruby-grape/grape-swagger/pull/510): Use 'token_owner' instead of 'oauth_token' on Swagger UI endpoint authorization. - [@texpert](https://github.com/texpert). | |||
| * Your contribution here. | |||
There was a problem hiding this comment.
Please return it after your changelog note
|
Hello, thank you for your contribution, this is a good feature, can you provide description of this feature in |
|
thanks @jordanfbrown … @jordanfbrown … please add a section to teh README (don't forget a TOC entry 😉), |
The current logic to determine a route's set of tags is based solely on the route, which works in most cases, but isn't flexible when you want to override the tags.
The situation that led me here was the following setup:
```
prefix 'locations/:id'
resource :employees do
desc 'Retrieve employees for a given location'
get '/' do
...
end
end
```
Which grouped the `/locations/:id/employees` under the `locations` namespace. This was undesirable, because almost all of the endpoints in our API are prefixed with `/locations/:id`, which meant that they were all grouped under the `locations` namespace.
Allowing an additional `tags` attribute on the `desc` method solved the issue for me.
```
desc 'Retrieve employees for a given location', tags: ['employees']
```
9340714 to
f187a52
Compare
|
@Bugagazavr @LeFnord Feedback addressed, thanks! |
|
👍 |
LeFnord
pushed a commit
to LeFnord/grape-swagger
that referenced
this pull request
Feb 9, 2019
The current logic to determine a route's set of tags is based solely on the route, which works in most cases, but isn't flexible when you want to override the tags.
The situation that led me here was the following setup:
```
prefix 'locations/:id'
resource :employees do
desc 'Retrieve employees for a given location'
get '/' do
...
end
end
```
Which grouped the `/locations/:id/employees` under the `locations` namespace. This was undesirable, because almost all of the endpoints in our API are prefixed with `/locations/:id`, which meant that they were all grouped under the `locations` namespace.
Allowing an additional `tags` attribute on the `desc` method solved the issue for me.
```
desc 'Retrieve employees for a given location', tags: ['employees']
```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current logic to determine a route's set of tags is based solely on the route, which works in most cases, but isn't flexible when you want to override the tags.
The situation that led me here was the following setup:
Which grouped the
/locations/:id/employeesunder thelocationsnamespace. This was undesirable, because almost all of the endpoints in our API are prefixed with/locations/:id, which meant that they were all grouped under thelocationsnamespace.Allowing an additional
tagsattribute on thedescmethod solved the issue for me.Before:
After:
Is there another way to accomplish this that I missed altogether, or does this seem like a reasonable addition?