-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V2 - Why is OpenAPISchema.Type of type "object"? #1874
Comments
I hadn't noticed this. I agree that making the type property of type object is not going to be a great experience. However, I'm not sure making it an array is the right choice considering how commonly devs will only want to set a single value. Could we make a |
According to the doc comments, it says that:
Is there a situation where it's not a string or an array of strings? I agree with making it an enum since we know the possible values. We can even add a member for unexpected types and show a validation error. |
@darrelmiller with modern CSharp (12) people can simply write collection expressions schema.Type = [SchemaType.Object]; (assuming we go with an enum) @calebkiage I think this is simply an abstract of the JSON schema spec at the end, the possible values here being constrained to a set we know in advance, we might as well use an enum. |
Interestingly enough STJ chose a flaggable enum, which is another option we haven't considered. They do not have a developer experience requirement though, since everything is internal (and that's too bad since we could have reused a lot of what they've built) |
This provides a really poor development experience, forcing the consumer to implement complex type assertions when it shouldn't be required.
And then we do things like those:
OpenAPI.NET/src/Microsoft.OpenApi/Models/OpenApiSchema.cs
Line 839 in 3c64451
Which is not only going to be slow, but also problematic for people using AOT/trimming.
We already know that OAS 3.1 and Json Schema only support the following types:
(maybe we could add compatibility with the integer mess).
Why not instead:
The text was updated successfully, but these errors were encountered: