Open baywet opened 1 week ago
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 HttpMethod
style class that does some operator overloading to handle assigning both simple values and arrays?
According to the doc comments, it says that:
Value MUST be a string in V2 and V3
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. https://github.com/dotnet/runtime/blob/5e9a425ed90f30f92eb3d2d4b25179efe8255232/src/libraries/System.Text.Json/src/System/Text/Json/Schema/JsonSchemaType.cs#L11
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: https://github.com/microsoft/OpenAPI.NET/blob/3c644511afba381b0c580f31d7282ac1e98c8d41/src/Microsoft.OpenApi/Models/OpenApiSchema.cs#L839
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: