exegesis-js / exegesis

Tools for implementing server-side OpenAPI 3.0.0
MIT License
138 stars 35 forks source link

Automatic mock responses #114

Open alfirin opened 4 years ago

alfirin commented 4 years ago

Is-it possible to have an option or a plugin to automatically returns the answers provided in the swagger specification file inside a controller?

That will avoid us to create the same thing from the Swagger specification file and inside the controller.

Thanks a lot for your help.

jwalton commented 4 years ago

You're not the first person to ask about this. It should definitely be possible.

We have infrastructure for plugins already which should have most of what you'd need to do this. Off the top of my head, if I was going to do this, I'd traverse all the paths in the apidoc at the top level of makeExegesisPlugin() (because this is where you're allowed to modify the apidoc) and replace all the x-exegesis-controllers with something like mockController, and for each one I'd add a new method to my mockController object which just returns whatever the first defined response is for that path.

The first tricky bit is constructing a valid response; if there's an example at the top level of the schema object, you can just steal that, but if there isn't you'd have to use something like json-schema-traverse to walk the schema and construct a valid example as you go. swagger-ui does something similar to generate examples, so you might be able to steal some code from them, but it might be faster to just rewrite this from scratch (maybe make it a package in it's own right... Or, now that I say that, maybe there's already a package out there that does something like this!)

The second tricky bit is, I'm not sure where you'd get a chance to insert the mockController. Again, off the top of my head, I'd suggest makeExegesisPlugin() should be passed an { apiDoc, options } object, with the raw objects that were passed into Exegesis, and then you could add your options there. The idea would be to let plugins modify the options object before it gets passed to compileOptions, because that does a bunch of sanity checking, adds default options, sanitizes the passed in bodyParsers, etc... and I don't think we'd want plugins to be mucking about with options after we do all of that. Might need a tiny bit of refactoring to make sure all the plugins get build prior to the call to compileOptions(), but that shouldn't be too bad.

I wouldn't mind taking a stab at something like this, but I can tell you we're a little short staffed at work right now, and I'm pretending to be DevOps and learning Kubernetes, so it might be a little while before I get a chance. But if you think that's enough to get you started, feel free to give it a go - I'm happy to answer any questions if you get stuck. :)

jwalton commented 4 years ago

json-schema-faker might be a good place to start for generating responses, although I bet it ignores the example keyword, because I'm pretty sure that's OAS3 specific.