Segregate objects types in responses

Mec-iS commented 6 years ago

Current responses may be mixing different types (like the State type nested into the Drone type). For example:

{
  "@context": "/api/contexts/Drone.jsonld", 
  "@id": "/api/DroneCollection/2", 
  "@type": "Drone", 
  "DroneID": "2", 
  "MaxSpeed": "300", 
  "Sensor": "Temperature", 
  "State": {
    "@type": "State", 
    "Battery": "81", 
    "Direction": "W", 
    "Position": "0.856901647439813,14.05823948684688", 
    "Speed": "100", 
    "Status": "Confirming"
  }, 
  "model": "xyz", 
  "name": "Drone 1"
}

The right way to return this data should be:

return the Drone object at /api/DroneCollection/2
In the "State" property, a reference should be present that points to the actual state in the shape of an hyperlink to the State object at /api/DroneCollection/2/State The same for other nested objects in the API. Every endpoint should return only one type of object.

Note: rememeber to update the ApiDoc repository as well

vddesai1871 commented 6 years ago

Hey, @Mec-iS I would like to work on this one. But I can't figure out why this issue is opened here and not in the hydrus repository and why we have to change the vocabulary, maybe I am missing something. What happens right now We have an endpoint to get an item from a collection. On GET request we call a method named 'get' in crud.py which fetch the item from the database and creates the response object similar to the one you have posted above. While doing so if the relationship is of type GraphIII (i.e. property of the object has value as an object) then we call get() method recursively to fetch that object. And add the object in the original response as a nested object. My approach Instead of recursively calling the 'get' method for a nested object we can get the class name of the object and create a link like api/XYZCollection/id/Class_name and set it as the value of the property(instead of nesting an object). We will have to define a new endpoint ( something like this :- APINAME + "///"). which will return the actual object. Is it the right way to go? If not then suggest a more proper way. I have this 3 questions : 1) why this issue is opened here and not in hydrus repository? 2) why we have to change the vocabulary? and 3) what's the best way to tackle this issue?

If you do not have time, refer me the documents or other sources from where I can get sufficient information, although it would be really helpful if you can resolve above-mentioned doubts and provide some guidance.

vddesai1871 commented 6 years ago

@Mec-iS @xadahiya @chrizandr can anyone give any clue about the solution?

xadahiya commented 6 years ago

why this issue is opened here and not in hydrus repository?

Moving to hydrus repo. PS: We need to fix this here as well so let's keep it open for now.

why we have to change the vocabulary?

Currently, we have two type of Collections (endpoint = True or enpoint = False). If some collection has endpoint=True then it'll be listed in the entrypoint else it won't be listed which makes perfect sense. I don't think we'll need to change the vocab a lot but again this depends on the approach we take to implement this. We can discuss this in detail during implementation whether we need to change the vocab or not.

what's the best way to tackle this issue?

Your suggested approach looks good to me. If anyone else has some better idea, please do comment below.

chrizandr commented 5 years ago

Rather than serving the property at something like /api/DroneCollection/2/State it would make more sense to serve it at /api/StateCollection/<uuid> since inherently State would also be stored at a separate endpoint given the way the server is created.

The reason for this would be that it would become easier to address multiple nestings that may occur if there are instance objects in the state property itself. Suppose State itself has a property called Sensor which is an instance, would this be served at /api/DroneCollection/2/State/<state_id>/Sensor/?

Each class instance has a unique URI already at ClassCollection/<uuid>, it would be redundant to serve them at two different URIs. The property can be linked directly to the instances unique URI, in this case /api/StateCollection/<state_uuid> for the coresponding state of the Drone.

Mec-iS commented 5 years ago

exactly, the demo should not serve full objects but hypermedia links. In Drone Collection: { "State": { "@id": "/api/StateCollection/<uuid>"}}

xadahiya commented 5 years ago

Moved and fixed in hydrus

HTTP-APIs / hydra-flock-demo

Segregate objects types in responses #34