Support Discriminator and DiscriminatorMap about huma HOT 2 OPEN

I'm also curious why this functionality is desired and what some examples of usage might be

I've got quite a few APIs in Python and PHP where the input looks like this:

{
  "type": "example",
  "dto": "on the backend is based onthe type"
}

Example in Swagger UI:

IMO, this is somewhat nicer for clients as it makes a particular field required vs...

In other systems like protobuf you don't really model explicit discriminated unions, it's more like a message with optional fields to all the other message types

Which would mean that all fields could be null or missing. That's an invalid request, but the OpenAPI spec doesn't really say that at least one is required.

I've also done stuff like this:

{
  "type": "example",
  "example_value": { ... }
}

Where the type makes an {type}_value or {type} field required. And it's fine, but, IMO the generated api spec doesn't do a great job of conveying which fields are required/not required, etc.

I was going to go down this route for now with my current project and just do a little more work in the handler.

It seems like this:

you can't list implementations of an interface via reflection

is the crux of the issue though. And using discriminator map could mean that a lot of sugar could be provided by Huma, but it'd still be pretty gnarly to support in request Body fields without full fledged support for union types in the go language itself.

Though maybe somethign like this could be done with generics now:

type RequestInput[T TypeOne | TypeTwo | TypeThree] struct {
  Body T
}

from huma.

@chrisguitarguy thanks for opening this issue. We don't currently have any special support for discriminator fields. Like you said, oneOf is supported in huma.Schema but is currently never generated from Go structs because Go doesn't have union types and you can't list implementations of an interface via reflection, plus there's a desire to generally keep things simple (i.e. Huma doesn't have to support all features of OpenAPI since OpenAPI is meant to describe all possible APIs).

That said, I'm not opposed to adding support for discriminators to huma.Schema for people who want to manually set them up, and like you said it may be possible to build some utilities on top of that (probably outside of the schema, maybe in a separate package?). I'm happy to review proposals and implementations with examples of how this would be used.

Given the potential complexity I'm also curious why this functionality is desired and what some examples of usage might be. In other systems like protobuf you don't really model explicit discriminated unions, it's more like a message with optional fields to all the other message types (possibly with a one-of, but that's just sugar it doesn't change the wire protocol or field names/types). Just trying to understand more about the use-cases and possible alternative approaches.

from huma.