Improve OpenAPI response schemas by marking guaranteed properties as required
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- openapi
- Domain
- api, backend-api-design
Research direction
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.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- JavaScript
- Stars
- 254
- Forks
- 53
- PR merge metrics
- No merged PRs in 30d
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from soundcloud/api
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
soundcloud/api#587 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 30/100
soundcloud/api#586 ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
soundcloud/api#581 · 1 comment ·
-
widget
Difficulty 5/5 Over a week Newbie friendliness 35/100
soundcloud/api#557 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
soundcloud/api#548 ·
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
curriculum documentation quality
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
githubnext/gh-aw-workshop#3897 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
agent/quality hive/hosted-available-lke648397-260827-5n31 quality testing
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
Maintainers usually reply within 1 day