Enhancements to Open Api Parser
Our last implementation worked okay , but in terms of features or ability to parse various open api specifications we were still lacking as the parser wasnt generalised enough. This week saw various enhancements , optimisations to the parser along with correction of many mistakes .
We had a lot of global variables which were defined in the main method , if parser was to be used as an independent module these variables would have to be initialised by the user which is certainly not what we want , so we created a method which could be the starting point for the process of parsing the documentation .
We were assuming the paths referred using the”$ref” key to be one level deep , this was a wrong assumption and a less generalised approach , so now we parse the location given in the “$ref” key iteratively till we reach the location given .
In the last implementation we only added classes which had corresponding paths defined , hence the classes we parsed from the “parameters” and “responses” key were not being added to the hydra api documentation , this was certainly not what we wanted hence we decided to remove the condition and loop through the “definitionSet” set and add all the classes that have been parsed .
The properties defined in “supported_prop” were not given a semantic reference , we discussed the best way to provide semantic references to these , we wanted to avoid using an external parser to parse resources like “schema.org” to fetch the reference ,hence we now maintain a dictionary containing semantic references for almost all the data types the open api supports so that we can directly fetch the references from there . In cases where we come across a local reference made like this :
category:
$ref:'#/definitions/Category'
we recursively go to the location parse the class , add it to the list of existing classes and point the semantic reference to this newly defined class .
In some cases where we came across class definition in the properties section itself like :
xyz:
type: "object"
properties:
id:
type: "integer"
format: "int64"
Did:
type: "integer"
format: "int64"
we parse this in a similar manner as we parse normal classes and after adding this to the list of already defined classes we are able to give a semantic reference.
We are still figuring out a way to attaching semantic references to properties of type:array . There are many optimisations that can be done , also @xaditya made changes to hydrus and now we can allow endpoints to be independent of class name . This will help us parse more methods and add them to the Hydra Api Documentation . We are also working on adding the ability to accept arrays as input in parameters .
This week will see some quick implementations and more improvements , stay tuned to know more !