Skip to content
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

Rethink Fury API #144

Open
kylef opened this issue Feb 5, 2019 · 1 comment
Open

Rethink Fury API #144

kylef opened this issue Feb 5, 2019 · 1 comment
Labels

Comments

@kylef
Copy link
Member

kylef commented Feb 5, 2019

There are some rough edges to the Fury API such as singleton pattern (#141 (comment)) and limitations of how adapters and media type handling works. The way that adapters declare media types and media type routing from Fury Core to the adapters is limited. For example, OpenAPI 2 and 3 should have same media type (application/vnd.oai.openapi) but the routing to two adapters is not possible.

The detection API is also a little cumbersome as each adapter provides serialsiation and some consumers want to be able to use detection without depending on parsers and serialisers etc. Hence why deckardcain was created to solve this need. We could rethink the API to allow detection to be slightly separate from paring and serialisation.

@kylef kylef added the core label Feb 5, 2019
@kylef
Copy link
Member Author

kylef commented Jun 5, 2019

Perhaps also the API should allow you to specify a path (or URL?) for the source to load it from disk, some similiar tools do so. Consumers of Fury core add this on themselves (fury-cli, Dredd, ApiaryUI, etc) and it will simplify the future when we support relative external referencing along with placing filename in the source maps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant