hydrus — New Features !

hydrus is an amazing tool for building REST API’s but every software deserves new features and upgrades , so we decided to add some new features to hydrus. We wanted some features like custom endpoints and arrays as input parameters in hydrus as we needed those so that we can parse open api document accurately and represent the api structure in a better way .

In hydrus the endpoint was same as the class name by default and there was no option to change this ,hence to allow users to define custom endpoints and to facilitate creation of endpoints like store/inventory/order we needed this feature . To implement we passed path during class creation and collection_path during addition of class to HYDRA api documentation. Other than this we had to change context and @id as well so that we can replace the endpoints from the class names to the user defined ones.

Finally from here

{
    "@context": "/serverapi/contexts/DatastreamCollection.jsonld",
    "@id": "/serverapi/DatastreamCollection/",
    "@type": "DatastreamCollection",
    "members": []
}

We came to this

{
    "@context": "/serverapi/contexts/DsCollection.jsonld",
    "@id": "/serverapi/DsCollection/",
    "@type": "DatastreamCollection",
    "members": []
}

After this , we realised that for inserting a number of objects we had to send individual requests to the server , if we had to add say a 100 objects we would have to send 100 requests , there has to be a better way !!!!

And so we created a new resource which would handle PUT and DELETE requests for multiple objects. For PUT user could either provide the ID’s or the server would auto-increment and provide ID’s automatically . User’s can provide , separated integers as ids in the path for both DELETE and PUT operations . This allows us to significantly reduce the number of requests sent to a server , we plan to introduce GET requests as well soon .

A put request with multiple Id’s

Now that i was done with implementing these features and writing tests for them i actually had to use these in the parser . Unfortunately when i tried to incorporate these changes i realised the architecture of parser was very rigid and tightly coupled , making changes in that felt like implementing hacks and was very untidy . The architecture was “smart” and worked well but it needed to be dumb and simple for easy upgradation , hence i made a very hard decision to rewrite the whole parser .

But this time i did things differently , i broke down the steps that had to be performed to create a HYDRA documentation and i realised i need to create the documentation at the end , i should parse first then create the documentation , earlier we were doing both side by side which made things messy . Hence for storing all this information i created a global state which contained the following :

class_names:{PET,USER},
doc: OAS DOC
PET: {
    "class_name": "Pet",
    "class_definition": HydraClass,
    "prop_definition": list(),
    "op_definition": list(),
    "collection": False,
    "path": "/pet"
}
USER:{
    "class_name": "User",
    "class_definition": HydraClass,
    "prop_definition": list(),
    "op_definition": list(),
    "collection": False,
    "path": "/user/create"
}

With this dictionary i could keep track of all the data that has been passed , edit it easily , validate easily and in the end i could parse all this and create a document , very simple (which was the motive )

I rewrote this implementation in less than 1.5 days , it does require some alterations to make it perfect but working on this has become easier and i can incorporate changes easily .There are some other things that HYDRA cannot do at the moment but OAS can , i have written to the community asking for solutions and probably i will receive some great insights from there .

Till the next blog , Ciao !