Do not use tags for grouping controllers
Open
Nobody has claimed this yet.
design discussion required
good first issue
hacktoberfest
- Dominant language
- Kotlin
- Stars
- 4
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
Problem:
Currently, operations and paths are clubbed into a controller based on tags. This approach has some limitations:
- tags are not mandatory in spec yml and we haven't mandated them in apifi too
- tags are an array. So mapping that to one controller doesn't sound right
- currently, if
tagsare not specified, no controller is generated. Since we are not mandating it, controller should get generated with default Path's name.
We can use operationId by some convention with a delimiter to signify controller name or controller group.
Things to be taken care of once issue is resolved:
- Add a migration doc to let users know how to move from
tagstooperationId. - Release a new version.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how tags currently group operations and paths into generated controllers, then inspect how operationId values are handled. Define and document the operationId grouping convention, including the default controller name when tags are absent. Update the migration documentation and verify the release requirements are addressed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100