Improve OpenAPI response schemas by marking guaranteed properties as required
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- openapi
- Área
- api, backend-api-design
Línea de trabajo
Start by locating the OpenAPI response schemas and comparing their properties with the actual API responses to identify values that are guaranteed to be present. Review the securitySchemes definitions and the separate secure.soundcloud.com host question as part of the scope. Done means guaranteed response properties have accurate required arrays and the OAuth path decision is documented.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The OpenAPI specification appears to be missing required declarations for many response properties.
For example, properties that appear to be consistently returned by the API are not included in the schema's required arrays. This causes OpenAPI-generated clients and TypeScript types to treat these properties as optional, even though they appear to be guaranteed in actual API responses.
Could the response schemas be reviewed and have properties marked as required where they are guaranteed to be present?
This would make the OpenAPI specification more accurately reflect the actual API contract and would improve the quality of generated clients.
One related question: OAuth is currently represented through the securitySchemes definitions, with the authorization and token URLs hosted at https://secure.soundcloud.com rather than the API host. Is the intention that the OAuth endpoints themselves are intentionally excluded from the OpenAPI paths, since they belong to the separate secure.soundcloud.com service?
- Lenguaje dominante
- JavaScript
- Estrellas
- 253
- Forks
- 53
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 soundcloud/api
-
Platform availability issuesAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
soundcloud/api#587 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
soundcloud/api#586 ·
-
Feature request: Liked stationsAbiertoenhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
soundcloud/api#581 · 1 comentario ·
-
widget
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
soundcloud/api#557 · 1 comentario ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 38/100
soundcloud/api#548 ·
Todos los issues de soundcloud/api
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día
-
Design only Leadership Survey SLFS
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
bcgov/digital-journeys#2293 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
tursodatabase/turso#9405 ·
Los mantenedores suelen responder en 1 día
-
Toolkit
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
API Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
ProjectSidewalk/SidewalkWebpage#5556 ·
Los mantenedores suelen responder en 1 día