Improvement idea: add `choice` prop to features giving a subclass

Just like the title says. There are feautres, where you choose something form an array of opitons, be it expertise, eldritch invocation or fighting style. Why not treat subclasses the same way?

Proposed structure:

{
    "index": "otherworldly-patron",
    "class": {
        "index": "warlock",
        "name": "Warlock",
        "url": "/api/classes/warlock"
    },
    "name": "Otherworldly Patron",
    "level": 1,
    "desc": [
        "At 1st level [yada yada]."
    ],
   "choice: {
        "choose": 1,
        "type": subclass
        from: "api/classes/warlock/subclasses"
    }
    "url": "/api/features/otherworldly-patron"
}

I know there is only one subclass in the SRD, but as y’all mentioned before, if something comes from a feature, you like to keep it within that feature, so why not add information about subclass choices to the feature giving you a subclass?

[Freedzio]

When you put it that way, ye, my propositon would stir some disinformation. feature_specific approach is cleaner. It indicates that this feature has some logic/complexity behind it and allows the api cosnumer to deal with it the way it needs to. Just like class_specific data

[fergcb]

Yeah, this is exactly what I meant when I was talking about how the feature_specific property would help keep things organised as we expand on all the features in this way.