Define reusable type definitions under "components -> schemas"

[Apollo3zehn]

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:

hdf-rest-api/openapi.yaml

Lines 2081 to 2094 in e6f1a68

	type: object # TODO: is this complete?
	properties:
	created:
	type: number
	href:
	type: string # TODO: investigate
	name:
	type: string
	shape:
	type: object # TODO: specify?
	type:
	type: object # TODO: specify?
	value:
	type: string # TODO: whatever the user put there

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

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

[ajelenak]

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.