HDFGroup / hdf-rest-api

12 stars 5 forks source link

Define reusable type definitions under "components -> schemas" #12

Open Apollo3zehn opened 1 year ago

Apollo3zehn commented 1 year ago

I have auto-generated an HSDS API client based on the openapi.json present in this repository. One big problem I encountered is that there are many anonymous type definitions. I.e. there are many response types ("schemas") that are defined anonymously in the response section instead of being in the OpenAPI components -> schemas section where they are reusable and named.

Here is an example of how the types are defined in the components -> schemas section in a different project: https://github.com/malstroem-labs/nexus/blob/db7335dfaca71ba3f82aa1e2d0a8b46dbfe61410/openapi.json#L1701

And here is how they are being referenced:

https://github.com/malstroem-labs/nexus/blob/db7335dfaca71ba3f82aa1e2d0a8b46dbfe61410/openapi.json#L76-L83

Due to the repeated and sometimes incoherent definitions of the same anonymous types I have trouble to e.g. extrac the type information about an attribute from the /{collection}/{obj_uuid}/attributes endpoint. Here is the part where the response would have been defined but unfortunately there is no definition except the top-level properties:

https://github.com/HDFGroup/hdf-rest-api/blob/e6f1a685c34ce4db68cdbdbcacacd053176a0136/openapi.yaml#L2081-L2094

In my generated C# codes this leads to an empty list of properties:

grafik

Please tell me, if you think it is better to posts these kind of questions to the HDF forum. Thanks :-)

ajelenak commented 1 year ago

Please tell me, if you think it is better to posts these kind of questions to the HDF forum.

Thank you for doing this. Unfortunately, that OpenAPI document is far from complete or even accurate. I don't think the company has resources to fix it any time soon so if you are willing please submit PRs with changes.