GSOC 2020-WEEK 6

Priyanshu Nayan
3 min readJul 22, 2020

So, I have passed my first evaluations, so its amazing. After the evaluations we started working on adding some important concepts in the core library and the processing of API document by expanding it first and then making the classes of cores, like HydraDoc, HydraClass, etc.

Implementation

First we worked on the adding the hydra:collection array in the entry-point. The entrypoint informs the client all the possible endpoints that a client can visit. The endpoints can be a hydra class or hydra collection. Earlier it was not possible to identify which endpoints are classes and collection from the endpoint, so to make it explicit we decided to use a self explanatory array called hydra:collection which contained links to all the collection endpoints. Hence, the entry point became more meaningful.

Second thing we worked was adding the hydra:manages block. This block allows writers to give explicit description to the members of the collection. This block allows subject, property, object keys out of which only two are accepted in one block. Though there can be multiple manages block about a collection. Earlier in the entrypoint, collections did not contain other information like it's title, type or the types of operations it supports. So, we added all the relevant information about the collections along with the manages block. The client doesn't have to move back and forth to the api doc to know about a collection.

The above two improvements are done in the PR:

Next, we started working on expanding the API documents before processing them. We discussed all the pros and cons of the algorithms like framing, and decided to move ahead with the expansion API. This task turned out to be more lengthy then expected. I got stuck multiple times and was rescued by our cool mentors Chris and Akshay and amazing teammate Samesh.

At first I faced a problem that how do we create entrypoint from the APIDOC. So, right now, what we do is that we find the EntryPoint Class or basically any class that has supported properties as hydra:Link to other classes, and we check the range of that property to identify the if its a class or collection and allot them the right list. This is important decision to take, because range can create super class or just hydra:Resource, but we think that explicitly defining the classes and collections makes more sense, and removes a lot of complications.

It’s still a work in progress: corresponding PR:

Learnings

I get to learn about what it takes to make decisions while developing features. Lots of work to de done after depends on this and it just takes one bad call to create a whole lot of complications and makes it difficult to work on the project.

I got to know in depth about manages blocks and other hydra features.

--

--