OpenAPI.NET icon indicating copy to clipboard operation
OpenAPI.NET copied to clipboard

V2 - Why is OpenAPISchema.Type of type "object"?

Open baywet opened this issue 1 year ago • 4 comments

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:

  • null
  • boolean
  • object
  • array
  • number
  • string

(maybe we could add compatibility with the integer mess).

Why not instead:

  • Define an enum for those types
  • Make the type property, an array/list/enumerable of that enum
  • When serializing as v2/v3, ensuring that we emit the right compatible information.

baywet avatar Oct 14 '24 19:10 baywet

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?

darrelmiller avatar Oct 14 '24 20:10 darrelmiller

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.

calebkiage avatar Oct 15 '24 09:10 calebkiage

@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.

baywet avatar Oct 15 '24 12:10 baywet

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)

baywet avatar Oct 16 '24 11:10 baywet