Enhancements to Open Api Parser

Vaibhav Chellani
openapi-hydra-parser-gsoc2018
2 min readJun 30, 2018

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 !

--

--