Comments (13)
Re-opening as express-openapi should aim to be as un-opinionated as possible to follow express's purpose Fast, unopinionated, minimalist web framework for Node.js
.
from open-api.
Yes, that also sounds fine, I'll see if I can implement this this week.
from open-api.
So you can define paths in apiDoc.paths
, and express-openapi
will inherit from it, except for handlers.
What you would consider limiting, I would consider freeing.
Consider that you never have to duplicate a path, as it's entirely inferred from fs.
from open-api.
Also, your documentation is kept up to date for users. So if you delete a handler, you don't have to worry about your docs getting out of sync. This is what bothers me about other frameworks that expect a monolithic json document or yaml doc to describe their apis.
from open-api.
OpenAPI spec has $ref
for Path Object
from open-api.
Thanks for re-opening this, it sounds like we could pull out the current convention over configuration router part of express-openapi into a separate middleware.
BTW I've successfully used a few of the express-openapi middleware with Koa, the middleware strategy you have chosen works really nicely.
from open-api.
@dalejefferson glad to hear the middleware strategy is working out for you!
I've had a few thoughts related to closing out this ticket:
- Add a new argument to the initialization args that specifies either a module or a directory (haven't decided which would be more friendly).
- This argument will define the operation handlers for the provided
apiDoc
. - Operation handlers are referenced via
operationId
in theapiDoc
.
from open-api.
A related issue is that the reliance on fs-routes makes it totally impossible to package an app using express-openapi using webpack or similar tools. I'd like to be able to provide express-openapi with a list mapping urls to module paths or already loaded modules.
from open-api.
@mika-fischer PRs are always welcome!
from open-api.
@jsdevel I might give it a go. But what would your preferred API look like?
My idea would be to make the paths
option optional, and add a new option (maybe routes
or urls
(?)) and allow to pass an array of objects: [ { route: 'foo', module: require('foo') }, ... ]
or [ { route: 'foo', path: 'foo' }, ... ]
, similar to what fs-routes generates.
That way most of the code could be reused...
from open-api.
@mika-fischer I think the paths
option array could also contain objects, and if no strings are in the array then we can skip the fs-routes call. Thoughts?
from open-api.
@dalejefferson see the great work @mika-fischer did in #60. I feel it closes this issue. Thoughts?
from open-api.
Thanks @mika-fischer this looks great, I will happily close this issue
from open-api.
Related Issues (20)
- [enhancement] openapi-response-validator: native ESM node modules default export not working as intended HOT 3
- [ft. request] openapi-response-validator - allow access to response param in errorTransformer HOT 1
- Using automatic paths with ESM HOT 2
- OpenAPI Types package, Path Item Object HOT 1
- Supertest integration tests fail after update to express-openapi 12.x.x
- parameters from Swagger 2.0 (openapi 2.0) YAML file are not caught by express-openapi HOT 2
- parameters from Swagger 2.0 (openapi 2.0) YAML file are not caught by express-openapi
- External refs not captured in parameters for request validation HOT 1
- Bug: OpenAPIResponseValidatorArgs responses object incorrectly defined
- Support for Asynchronous Custom Keywords in openapi-request-validator
- Support for validating OpenAPI 3.1
- Type narrowing
- [Bug] Custom formats not working for objects
- fs-routes is using a vulnerable version of glob HOT 1
- How to get the nice swagger page? HOT 1
- Path slash differences with Windows and Linux HOT 2
- Using `x-express-openapi-disable-validation-middleware` extension
- [openapi-types] V3.1 Schema Type Wrongly Referenced V3.0 Schema HOT 1
- Cannot disable defaults middleware HOT 1
- [openapi-request-validator] CLI & YAML support
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from open-api.