OpenAPI file structure for Stoplight documentation
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- openapi, yaml
- Área
- api, documentation
Línea de trabajo
El issue no nombra archivos ni pruebas. Empieza revisando la estructura YAML actual de Stoplight/OpenAPI y las definiciones de API de CDS Events, Curb y Metrics; se considera terminado cuando cada API tiene su propio archivo YAML y todos los modelos compartidos se referencian de forma coherente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Is your feature request related to a problem? Please describe.
When we are building out the OpenAPI files within Stoplight, I believe we need to align on how we should structure the YAML files.
- Option A: 1 YAML file for all of the CDS APIs
- Option B: 1 YAML file for each of the CDS APIs
Describe the solution you'd like
I would like to pursue Option B which is the creation of a YAML file for each of the CDS APIs (Events, Curb, Metrics). This could make the documentation modular and easier to digest when being displayed through Stoplight.
Is this a breaking change
This isn't a breaking change since we have yet to finalize a full Open API version on our documentation
Impacted Spec
All APIs are impacted with this documentation standard.
Describe alternatives you've considered
We would want to use Stoplight to create shared models that can be referenced by multiple APIs if these are needed. This proposed structure does not conflict with previous decisions to maintain a single branch for each API version.
Additional context
Several members of the CDS WGSC collectively showed support for the option to move towards a model where 3 distinct files were used to document each API in the Oct 11th WGSC meeting.
- Lenguaje dominante
- JavaScript
- Estrellas
- 7
- Forks
- 0
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de openmobilityfoundation/cds-openapi
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
-
TODO: Update the text table for event_purpose.yamlQuizá libre de nuevo @michael-danko-passport la tomó hace 1154 días y no hay ningún pull request abierto. Abierto
openmobilityfoundation/cds-openapi#7 · 1 comentario · 1 asignado ·
-
Implement 501 status codeAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 32/100
openmobilityfoundation/cds-openapi#2 · 1 comentario ·
Todos los issues de openmobilityfoundation/cds-openapi
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
pedroapfilho/localveil#120 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
ImpactMojo/ImpactMojo#1385 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Seeed-Studio/wiki-documents#5974 · 1 comentario ·
Los mantenedores suelen responder en 1 día