Define a procedure to declare/generate ApiDocumentation

[Mec-iS]

Now that we have basic models and some kind of structuring of data, we need to define the ApiDocument endpoint.

[Mec-iS]

Operations are the basic ones as stated in #3: CRUDs implemented through HTTP methods.

As in Hydra spec:

...
  "supportedOperation": [
    {
      "@type": "Operation",     # Hydra:Operation
      "title": "Creates a new comment",    # description
      "method": "POST",    # HTTP method
      "expects": "http://api.example.com/doc/#Comment",    # class of objects expected as input, defined in the ApiDoc itself 
      "returns": "http://api.example.com/doc/#Comment",   # class of objects returned
      "possibleStatus": [
        ... Statuses that should be expected and handled properly ...
      ]
    }

For example, in our case expects would have as value Subsystem_Spacecraft, so this class has to be in the ApiDocumentation, so we need a script to "port" the RDF-OWL declaration into the Hydra document declaration.

[Mec-iS]

@xadahiya @chrizandr
NOTE: for now we are in the right direction but the ApiDoc is still too much hard-coded. Try to generate/modify it at server runtime, wecan follow to prossible strategies and use different fallbacks:

• parse the RDF vocabulary (if provided) and try to extract the ApiDoc from the metadata;
• read the structure of the data as it is dumped and try to extract the ApiDoc from the instance data.
  As much you can do about this at the moment is fine, it cannot really be a perfect/general mechanism at the moment. As a way to go, focus on the instance data to grasp a list of classes of resources (HydraClass) and eventual relationships between these classes from the dumped data, and the then apply CRUD operations to what it's found.

[chrizandr]

Doc writer #38

[Mec-iS]

ok. we need now to tell the end-user where he/she can write its own ApiDoc before running the app (same as WALK-THROUGH #54)