Use standard Openapi service slugs for subcommands
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 45/100
Direção de pesquisa
Start by reading the CLI command definitions and how they map subcommands to OpenAPI services; the issue names no files or tests. Compare the existing subcommand names with the service slugs used in console URLs, then check the CLI help output and tests for the resulting command names. Done means each service uses its console slug as its subcommand, with aliases avoided unless needed.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Description
Currently, subcommands within the CLI do not consistently follow a standardized naming convention. This can lead to confusion and friction when mapping CLI usage to official OpenAPI services.
We propose adopting slug-based subcommands aligned with the official OpenAPI service identifiers. These slugs are already used across OpenAPI platforms, particularly within the console portal URLs, and represent a well-established convention.
Proposal
Subcommands should use the same service slugs that are used in the OpenAPI console URLs.
For example:
- If a service is accessible via:
https://console.openapi.com/apis/<slug>/...
- Then the CLI subcommand should be:
$ openapi <slug> ...
This ensures a 1:1 mapping between CLI usage and official service naming, reducing cognitive overhead for developers.
Benefits
- ✅ Consistency with official OpenAPI ecosystem
- ✅ Easier discoverability and memorability
- ✅ Reduced need for documentation lookup
- ✅ Alignment between web console and CLI workflows
Additional Notes
- Slugs should be treated as stable identifiers.
- Avoid introducing aliases unless strictly necessary.
- Future services can be integrated seamlessly by reusing their existing slugs.
Example
If the console URL is:
https://console.openapi.com/apis/company/documentation
Then the corresponding CLI usage should be:
openapi company ...
- Linguagem predominante
- Rust
- Estrelas
- 19
- Forks
- 0
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de openapi/openapi-cli
-
Support content negotiation via `Accept` headerTalvez livre de novo @francescobianco assumiu há 135 dias e não há nenhum pull request aberto. Abertaenhancement
openapi/openapi-cli#3 · 1 responsável ·
Todas as issues de openapi/openapi-cli
Issues semelhantes
-
Expose the dot grid colourAberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
nannou-org/egui_graph#92 ·
Mantenedores costumam responder em até 1 dia
-
documentation good first issue
Dificuldade 2/5 Meio dia Facilidade para iniciantes 72/100
sujithputta02/Esapay#13 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
tursodatabase/turso#10002 ·
Mantenedores costumam responder em até 1 dia
-
needs triage
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
topgrade-rs/topgrade#2419 ·
Mantenedores costumam responder em até 1 dia
-
review-bot
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
midagedev/bloomery#318 · 1 comentário ·
Mantenedores costumam responder em até 1 dia