Open Api -> Hydra parser — Part 2

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

In the last implementation we had assumed a lot of things and were still figuring out how to map some specific open api objects to hydra object , in this new implementation things have *not* changed . Don`t be disappointed yet , this implementation was in the right direction and we moved to a new and efficient way of parsing the open api specification and generalised a lot of stuff , let me tell you how .

In the last implementation we parsed the definitions first , then parsed the paths and attached the classes when we get a reference of them in the parameters or response object . I decided to spice things up this time , i tried to parse the paths directly and when the parser came across a reference to class we went to the location where the class was defined and parsed the class as well .This way we could allow the user to define the class anywhere in the documentation , be it ‘definitions’ object or ‘components’ object or anywhere else .

In the last implementation we assumed collection to be false by default , we did not parse collections at all , in the revised implementation we have parsed the ‘type’ object defined in schema to check if its an ‘array’ which would mean that the endpoint is an collection .

try:
type = schema_block["type"]
if type == "array":
collection = "true"
else:
# here in type we will get object,string,integer etc
collection = type
except KeyError:
collection = "false"
return collection

Parsing the properties and checking if the property is a required property or not has also been implemented .

--

--