Use standard Openapi service slugs for subcommands
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 45/100
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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 ...
- Langage dominant
- Rust
- Étoiles
- 19
- Forks
- 0
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de openapi/openapi-cli
-
Support content negotiation via `Accept` headerPeut-être à nouveau libre @francescobianco l’a pris il y a 133 jours, et aucune pull request n’est ouverte. Ouverteenhancement
openapi/openapi-cli#3 · 1 personne assignée ·
Toutes les issues de openapi/openapi-cli
Issues similaires
-
agent:iq3-xxs area: cli duplication enhancement priority: P3 ready-for-agent
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
bytecodealliance/rustix#1703 ·
Les mainteneurs répondent en général sous 3 jours
-
bug discussion
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
medialab/xan#1201 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
farion1231/cc-switch#8298 ·
Les mainteneurs répondent en général sous 1 jour