On serialization
First thanks for working on a Golang project that understands/parses/validates multiple API specs!
I am using gnostic to parse & validate OpenAPIv3 specs (and later to validate API responses).
When translating from Gnostic's generated openapiv3.proto to my own intermediary format I noticed that some values have dubious defaults, such as OpenAPI's schema's minimum field:
https://github.com/googleapis/gnostic/blob/master/OpenAPIv3/OpenAPIv3.proto#L549
https://github.com/googleapis/gnostic/blob/master/OpenAPIv3/OpenAPIv3.go#L8100-L8102
IMO a boolean has_minimum should be introduced here, as a minimum of 0 is meaningful for real numbers.
Another note: it seems that OAS-flavored JSON schemas are not validated. They can contain type: 'blipblop' without issue.
Did I miss something? Is this planned to be supported?
I'm happy to open PRs!
I would also be very happy to see other Golang libs you like that
- parse at least OpenAPI specs
- validate the full spec (including OAS-flavored schemas), displaying useful warnings/errors
- can validate a net/http response against a spec
I'm building https://fuzzymonkey.co's client in Go but really the most complete libs seem to be in JS...
What do you think about using enums for, for instance, possible types?
enum Type {
any = 0;
null = 1;
boolean = 2;
integer = 3;
number = 4;
array = 5;
string = 6;
object = 7;
}
Also I think it's not too far fetched to drop Any in favor of something such as:
message JSON {
message Object {
map<string,Value> object = 1;
bool is_object = 2;
}
message Array {
repeated Value array = 1;
bool is_array = 2;
}
message Text {
string text = 1;
bool is_text = 2;
}
message Number {
double number = 1;
bool is_number = 2;
}
message Boolean {
bool boolean = 1;
bool is_boolean = 2;
}
message Null {
bool is_null = 1;
}
message Value {
oneof value {
Null z = 1;
Boolean b = 2;
Number n = 3;
Text t = 4;
Array a = 5;
Object o = 6;
}
}
}
JSON.Array enum = 2; // default: []
Hi @fenollp, thanks for looking at this! The gnostic .proto models are generated from JSON schemas and the generator is part of the project, so anything (like default values) that can be expressed in the schemas would be great to add - possibly including the richer JSON representation that you suggest.
Our interest is initially in supporting OpenAPI models that we produce for our own APIs, so there are some gaps (the Any type that you've found), but we'd like to make gnostic as useful as possible.
Maybe we could address these ideas point-by-point as issues with sample OpenAPI descriptions. Would that work for you?