API teams struggle to inspect complex schemas and responses
API developers and consumers run into gaps when documenting or exploring APIs with multiple possible response shapes. The reports describe oneOf variants missing from documentation UIs, having to inspect YAML or JSON, and being unable to launch related requests from displayed data. A separate request for boto3 type information points to a related need to inspect API types, though solving that well would require an AWS-specific integration.
For API developers and API consumers. Mentioned from Dec 2017 to Nov 2019 on GitHub.
4 different people described this problem in 4 separate discussions.
- Indie fit
- 4.0/10
- Pain
- 6.0/10
- Frequency
- 5.8/10
- Willingness to pay
- 0.0/10
- Momentum
- 5.0/10
- Who pays
- Businesses
- Competition
- High
- Build difficulty
- Medium
What people said
Quoted word for word. Follow a link to read the whole discussion.
I would be glad to see this implemented too. In the current state using multiple responses is not really usable because documentation consumer has to dig into YAML/JSON to find out all this information
This would be an amazing feature to have - currently struggling with documenting an api that would make great use of the oneOf feature as it could render foreignkeys or nested objects depending on query strings ( DRF FlexFields )
Build brief
See what to build and who will buy it
- 1 product idea with the smallest useful version and pricing
- 4 places to find your first customers
- 2 more quotes from people who have this problem
- Current workarounds, existing solutions and risks