16 findHWReservationById API response schema patch

[rinzler-17]

Addresses #51

Description
Following schema worked with the previous version of openapi-generator:

"customdata": {
"default": {}
}

When autocommit bumped the generator version to 6.3.0-SNAPSHOT, oas build errored which has been fixed with "default": null.
Also, response schema of findHardwareReservationById has been changed From Device to HardwareReservation.

[displague]

The backend allows for this field to be submitted as a JSON string ("customdata": "{\"foo\": \"bar\"}") or as an object ("customdata": {"foo":"bar"}).

When omitted in the request, the default value in the response is : {} (an empty object).

My inclination here would be to represent the field as an object with default {}. Is the problem that type: object and additionalProperties (https://swagger.io/docs/specification/data-models/dictionaries/#free-form) was not included in the OAS3 spec?

Suggested change

	+ "default": null
	"default": {},
	"type": "object",
	"additionalProperties": true,

[rinzler-17]

The backend allows for this field to be submitted as a JSON string ("customdata": "{\"foo\": \"bar\"}") or as an object ("customdata": {"foo":"bar"}).

So with this change, customdata will have one string key "{\"foo\": \"bar\"}" mapped to null or an empty string "" mapped to {"foo":"bar"} after deserialization?

[displague]

customdata is the key to an arbitrary value. You may submit a string, null, a boolean, or an object here.

However, if the request looks like quoted JSON, it will be parsed. See the "serialized in" columns of this table: equinixmetal-archive/packngo#225 (comment)

This is why I believe the best OAS3 approach will be additionalProperties: true, with type: object.

[rinzler-17]

Makes sense, incorporated suggestion in 2587209

[displague]

🙃 Nice find.

[displague]

Thanks, @rinzler-17. I'll start the process of upstreaming this spec change.