-
Notifications
You must be signed in to change notification settings - Fork 305
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
Add an OpenAPI doc for top level endpoints #298
Comments
This would play really very nicely in the broader ecosystem. It would be possible to generate clients for any number of languages, and could be used in robust property-based testing. |
Could we try to "automate" checking that this file is in sync ? |
Sure, if the OA spec is complete enough, In an ideal future world, I'd rather an OA spec was The Contract between an (even internal) plugin and the server. There is a python implementation of this approach, but it tries to do a lot, and work with a lot of different servers. Something like FastAPI takes a different, opinionated approach, but generated specs, used naively, doen't actually help you document/test your app over time. But if you generate and check in the spec regularly (e.g. as part of the build), and test against the spec, you get many of the same benefits. |
Yeah I could imagine that being sweet :) |
Hi @bollwyvl :)
We have it on the roadmap in Schemathesis, let me know how much generating different file uploads would help and I can prioritize this feature :) Currently, Schemathesis generates random bytes for file uploads |
hi @Stranger6667! impressive response time! I didn't meant to suggest Schemathesis was deficient in this manner, just that it's hard to put the idea of an upload into For Jupyter project in general, and for which a OA still has shortcomings, is websockets/zmq messages... I've been meaning to build some property-based tester for things like jupyter kernel messages and language server protocol stuff... so many things to test! |
Aha, got it :) I plan to take a look at this direction in the next few weeks or so. Feel free to ping me if you need any support from the Schemathesis side.
Just wondering if you are aware of AsyncAPI? It seems like a neat approach to describe message-based communication patterns. It also based on Open API, which is good since Schemathesis already knows how to generate data for it :) |
Yeah, have seen AA... but given that neither JKM/LSP even publish canonical JSON schema specifications, and represent pretty involved nested state machines with parallel states in n languages, and have (in)formal extension mechanisms... it would be a big lift to test, or at least believe that the tests were testing what you cared about. I'm thinking something like scxml would actually be needed, coupled with a proper message spec for the data model definition. So kinda next to |
We have an API file following the OpenAPI spec, but it does not cover all of the URLs.
We should have another top level doc for the other endpoints, such as
/file
, and the directory handlers added in #251The text was updated successfully, but these errors were encountered: