Comments (3)
Hi @pvince,
Just a quick observation.
Instead of posting to ‘POST /api/v0/{grouping}/items/generate’ why not post to ‘POST /api/v0/{grouping}/items‘ this would follow the more RESTful pattern of creating resources.
from exegesis.
I am simplifying the use case a bit here.
The items are created based on a template, and depending on how that template is structured and the options passed to 'generate' a variable number of items can be created. Further, the generated items are tied back to the template that was used to create them. Finally, at this time we didn't want to let people directly 'create' the items, but there might be a point in time where we could let them do that, and we didn't want to change the definition of what it meant to POST to the ../items.
The templates are managed through a separate endpoint, and they can be individually created via a POST.
from exegesis.
Yeah, it would be nice if this was a little more deterministic. I'm in the middle of crunch time over here, so I won't get to work on this until about a week from now. But I'll toss out some brainstorming here.
The relevant part of the spec says:
When matching URLs, concrete (non-templated) paths would be matched before their templated counterparts. Templated paths with the same hierarchy but different templated names MUST NOT exist as they are identical. In case of ambiguous matching, it's up to the tooling to decide which one to use.
So the good news is, we can do whatever we want! :D
Doing it based on which path matches first in the JSON/YAML would be nice, and easy to understand. The one downside to this is that, paths are stored as keys on an object in OpenAPI, and technically, according to the ECMAScript spec the keys in a JSON object are unordered. Most implementations (like node) will give you back keys in the same order you define them, but even node can violate that if you call delete
on a key. That's perhaps being a bit pedantic though. Matching the "first" one also means we can break out of that loop early, which I like.
If we really want to be safe, we could go by order, and also add an extension to open-api so you can explicitly specify the order (like have an x-exegesis-path-priority: 1
to prefer path A over path B with x-exegesis-path-priority: 2
, then we can sort them based on priority).
I am not sure if there is a way you can change the code to build up a list of 'matched' paths, and then prefer paths that have more 'fixed' values over paths that have more variables?
I like that. Maybe we could store a count of template variables with each path, and then when we match if we match more than one of them we pick the one with the lowest count? I was going to say "Too bad we can't break out early here", but actually we could combine this with the idea above and automatically assign priorities to paths based on the number of template variables. Then ordering largely doesn't matter. Or maybe sort by explicit priority first, then within each explicit priority sort by variable count. That gives you a fair amount of flexibility.
Or maybe that's a little too fancy, and we should just sort by template variable count for now and worry about custom priorities later if they're actually needed?
from exegesis.
Related Issues (20)
- Validation error of request body when oneOf is used HOT 5
- Crash with recursive definition in referenced OpenAPI file is back again
- Does not work well with newest json-ptr (1.3.1) HOT 2
- Your .dependabot/config.yml contained invalid details HOT 1
- Export class from controller HOT 2
- Could not find controller if controller is a .ts file HOT 2
- Can we access "ExegesisContext" at express middleware(app.use) not controllers/*.ts HOT 1
- How to filter the request body by only passing the defined requestBody schema? HOT 2
- Security vulnerability in `json-ptr` HOT 4
- Exegesis 3.0.0 using updated ajv outputs issues with OpenAPI spec, but 2.0.0 did not HOT 5
- res.redirect not supported HOT 3
- Is OpenAPI 3.1 supported?
- Bump json-ptr to fix security vulnerability HOT 1
- Support for additional string formats HOT 2
- json-schema-ref-parser dependency breaks node engine < 17 HOT 3
- How to use exegesis with multipart/form-data?
- Mime-types HOT 2
- Query parameters not being validated. HOT 1
- Loading is too slow due to schema compilation HOT 2
- Skip/bypass response validation HOT 2
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 exegesis.