Use standard Openapi service slugs for subcommands
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 45/100
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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 ...
- Vorherrschende Sprache
- Rust
- Sterne
- 19
- Forks
- 0
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus openapi/openapi-cli
-
Support content negotiation via `Accept` headerEvtl. wieder frei @francescobianco hat das vor 132 Tagen übernommen, und es ist kein Pull Request offen. Offenenhancement
openapi/openapi-cli#3 · 1 zugewiesene Person ·
Alle Issues in openapi/openapi-cli
Ähnliche Issues
-
area::tern-sync kind::cleanup triage::ready
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
review-bot
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
midagedev/bloomery#160 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
oxidecomputer/humility#737 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 65/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Maintainer antworten meist innerhalb von 1 Tag