Use standard Openapi service slugs for subcommands
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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 ...
- Lingua principale
- Rust
- Stelle
- 19
- Fork
- 0
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di openapi/openapi-cli
-
Support content negotiation via `Accept` headerForse di nuovo libera @francescobianco l’ha presa 135 giorni fa e non c’è nessuna pull request aperta. Apertaenhancement
openapi/openapi-cli#3 · 1 assegnatario ·
Tutte le issue di openapi/openapi-cli
Issue simili
-
area: compat area: parsing bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
reubeno/brush#1526 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
OFN writer emits `DocIRI` as a bare IRI, which becomes a version IRI or a parse error on re-readAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
phillord/horned-owl#338 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
type/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
stackabletech/operator-rs#1301 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
jmcnamara/rust_xlsxwriter#205 · 4 commenti ·