We’ve always strongly discouraged against poor API Designs with unknown polymorphic data types like this which is going to be a source of runtime issues that wont be able to work with most Add ServiceStack Reference languages. Whilst polymorphic types in DTOs are heavily discouraged, at the very minimum BaseResponseModel should be an abstract type to force embedding __type info.
Which doco is telling you to change TypeAttr to use $type?
I would recommend following the same approach Amazon does in its DynamoDB APIs that need to handle multiple different Types in its AttributeValue Type where it contains a DTO with explicit properties for different value types.
Basically the 2 approaches I would take to model this in a Typed API is to either flatten all types to use a single type with a Type indicating what Type it is, e.g:
public ResponseModel
{
public string Type { get; set; }
//.... All properties from all sub Types
}
// Which you can use as normal:
List<ResponseModel> Results { get; set; }
Then if you need to in your App you can convert the flatten DTO ResponseModel into your preferred .NET polymorphic types.
Or have a strong typed collection for each model, e.g:
public List<TextModel> Texts { get; set; }
public List<NumberModel> Numbers { get; set; }
The other lesser recommended approach is to change to use unknown object like List<object> where it gets deserialized into an untyped object dictionary that you dehydrate back into your preferred Type, in which case the FromObjectDictionary extension method can help convert an object dictionary into a concrete type.