Transforms a Hydra API doc in an intermediate representation that can be used for various tasks such as creating smart API clients, scaffolding code or building administration interfaces.
I'd like to be able to initialize the API specs from an existing cache in order to get the most recently known state of the api docs in case of offline usage.
Basically I need to be able to serialize the specs into JSON and deserialize from JSON. As far as I can see the tests currently utilize JSON.stringify() already which is nice but in my case I'm getting issues with an API spec which has circular references internally (e.g. a Resource is referencing another Resource its Field.reference property).
As the parseHydraDocumentation is capable of creating those references properly based on the api docs I'm currently thinking that utilizing the collected response(s) for caching and instantiate a new instance of Api with its belongings from that state.
If I see it correctly it should be sufficient to separate the "fetch" and "parse" capabilities that are currently handled implicitly in the parseHydraDocumentation - like having one separately exported function that does only the parsing which is currently done here:
Hi,
I'd like to be able to initialize the API specs from an existing cache in order to get the most recently known state of the api docs in case of offline usage.
Basically I need to be able to serialize the specs into JSON and deserialize from JSON. As far as I can see the tests currently utilize
JSON.stringify()
already which is nice but in my case I'm getting issues with an API spec which has circular references internally (e.g. aResource
is referencing anotherResource
itsField.reference
property).As the
parseHydraDocumentation
is capable of creating those references properly based on the api docs I'm currently thinking that utilizing the collected response(s) for caching and instantiate a new instance ofApi
with its belongings from that state.If I see it correctly it should be sufficient to separate the "fetch" and "parse" capabilities that are currently handled implicitly in the
parseHydraDocumentation
- like having one separately exported function that does only the parsing which is currently done here:https://github.com/api-platform/api-doc-parser/blob/a9e097339ecd88b0515238c49e504ff17edcc1c3/src/hydra/parseHydraDocumentation.js#L196-L442
I could try to come up with a PR for this but I'd like to get some opinions on that first.
Best