-
Notifications
You must be signed in to change notification settings - Fork 115
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
Discoverability #74
Discoverability #74
Conversation
Very good! This is something I've been contemplating. I'll have look over this over the next day 👍 |
Just thinking we should probably use a reserved path for stuff like this. This also might be good because some users may want to specify For examples: Would be handy to do this so we can then add more paths to this mount point for other functionality that represents drakov specific endpoints. Let me know what you guys think. ping @SiCurious @kosmotaur |
My other though was that it would be nice (maybe in another PR) to do |
@SiCurious @kosmotaur I'm happy to merge this in and we'll change discovery endpoint to the reserved mount point of |
Yeah, that makes sense to me. The JSON discoverability object is a great idea and would help with automated discovery. |
Merging now 👍 Will shortly update the routes to use the new reserved mount point of Thanks again for the contribution guys 👍 |
discovery URL mount point changed in 2363cd5 |
Hi!
We've created a basic discover page. The use case is, that if we serve the blueprints on our internal network, and people visit its URL, it has been voiced that they could very much use a listing of all the endpoints exposed.
It is a bit rudimentary, and we plan on utilising Aglio to make it a beaut, but didn't want to introduce a dependency that big into Drakov. That's why the
-D
option accepts a string value, which would be the module to require to build the middleware to handle the discover page. We'll build that module separately.Kind regards,
@SiCurious and @kosmotaur