-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose the inputs and outputs in the openapi.json files #672
Comments
Hey @MatthieuBizien thanks for the detailed notes here! We discussed this suggestion internally and feel it's a bit too early. I'm going to close this issue but we'll take another look at it sometime in the future. In any case, if you're strongly in favor of this, we would be open for a PR. |
Actually, we decided to keep it open for now :) |
Same as #2364, closing as there is more activity on that one. Thanks for the request @MatthieuBizien |
Reopening this. For the client, we already have the ability to programmatically inspect the APIs using the Slack discussion: https://huggingface.slack.com/archives/C02SPHC1KD1/p1680887663305069?thread_ts=1680694519.500639&cid=C02SPHC1KD1 |
Is your feature request related to a problem? Please describe.
Gradio documents the API in the
/api
route, which is really nice for understanding an API.Having a machine-readable version of that page would be very useful for automatic verification of the coherency of the gradio, including:
Describe the solution you'd like
The standard place for that information would be /openapi.json , that can represent data models, including:
The JSON keywords also match most of the options of the Gradio inputs, incl.
Additional context
Because Gradio use FastAPI + Pydantic + Swagger, it could be enough to define dynamic Pydantic models and use them when creating the application.
An alternative solution would be to just expose the data of the /api route as json, without using the standard.
The text was updated successfully, but these errors were encountered: