Remove redundant race and subrace data

[LarsGast]

I've analysed the race and subrace data and found that the properties race.starting_proficiencies, race.starting_proficiency_options, subrace.starting_proficiencies, and subrace.language_options can be considered redundant for all races and subraces in the SRD. The data that these properties hold can be found on corresponding traits that are linked to the races/ subraces. You can find the analyses in this gist (races) and this gist (subraces).

Some examples:

• Elves get the Keen Senses trait, which grants proficiency in the perception skill.
• Half-Elves get the Skill Versatility trait, which grants a proficiency in two skills of their choice.
• Rock Gnomes get the Tinker trait, which grants proficiency in Tinker's Tools.
• High Elves get the Extra Language trait, which grants them one known language of their choice.

The data of all of the above examples is available as structured data on the race/ subrace AND on the corresponding traits, which are also linked to the race and subrace using the race.traits and subrace.racial_traits properties or using the /api/2014/traits/:index endpoint.

This means that the properties race.starting_proficiencies, race.starting_proficiency_options, subrace.starting_proficiencies, and subrace.language_options can safely be removed from the race and subrace model without losing any data. Consumers of the API can instead fetch the traits linked to the race/ subrace to get the same data. Removing these properties from the race and subrace models would reduce the response sizes (only get the data that you need), and would also reduce the complexity of the model (do Half-Elves get 2 skill proficiencies (the data of which is present on the race and on the trait), or do they get 2 from the race and 2 from the trait?).

My suggestion if the following:
Remove these properties from the race and subrace models to remove redundancy and reduce confusion for the API consumer about which properties to use to get the correct data. This way the consumer does not have to choose which property to use and can not accidentally use both properties (making it seem like the race/ subrace gets multiple of the same proficiencies/ proficiency choices/ language choices).

[LarsGast]

It seems like subrace.languages is an empty array [] for all subraces in the SRD API database. This could also be seen as redundant data. There isn't a single subrace in the PHB that gets an extra language other than the High-Elf, which gets the Extra Language trait, which as we already established is redundant data on the subrace model.

I could see that one would want the subrace.languages property to be part of the model, because then it's easily expandable with data not in the SRD. However, since this property contains no data for any subrace in the SRD API, I would be in favor of removing it, just like the other redundant properties.

[LarsGast]

I just noticed that the endpoints /api/2014/races/:index/proficiencies and /api/2014/subraces/:index/proficiencies can be used to get all proficiencies of a race/ subrace. Maybe it is worth looking into doing something with these endpoints as well. Seeing that there isn't an endpoint for getting the proficiency choices or language/ language choices, it seems to me that these endpoints play a specific role that 1. might be rendered redundant after completing this issue, and 2. is not being applied in other instances similar to this one.

[LarsGast]

It seems like subrace.languages is an empty array [] for all subraces in the SRD API database. This could also be seen as redundant data. There isn't a single subrace in the PHB that gets an extra language other than the High-Elf, which gets the Extra Language trait, which as we already established is redundant data on the subrace model.

I could see that one would want the subrace.languages property to be part of the model, because then it's easily expandable with data not in the SRD. However, since this property contains no data for any subrace in the SRD API, I would be in favor of removing it, just like the other redundant properties.

I pushed a separate commit in both projects that removes the subrace.languages property to make it easily revertible. I think this can safely be removed, but maybe it requires some more discussion.

[bagelbits]

@LarsGast I think you have a linting error to fix in the API, but this looks right.

I think removing subrace.languages makes sense. Especially if it's always [].

Regarding /api/2014/races/:index/proficiencies and /api/2014/subraces/:index/proficiencies, I can see two paths:

• Remove them as redundant
• Expand them to include choices and add /api/2014/*/:index/languages.

For the latter case, you would end up with the proficiencies endpoint returning a list of proficiencies and choices, which may be an unexpected response. It might be better to separate them into keyed traits on the response, but that would also be a breaking change to the endpoint itself.

I wonder if it's better to just remove it for now and re-add it later if we have a better use case.

[LarsGast]

@LarsGast I think you have a linting error to fix in the API, but this looks right.

Fixed in 5e-bits/5e-srd-api@2e2198e

[LarsGast]

Regarding /api/2014/races/:index/proficiencies and /api/2014/subraces/:index/proficiencies, I can see two paths:

* Remove them as redundant

* Expand them to include choices and add `/api/2014/*/:index/languages`.

For the latter case, you would end up with the proficiencies endpoint returning a list of proficiencies and choices, which may be an unexpected response. It might be better to separate them into keyed traits on the response, but that would also be a breaking change to the endpoint itself.

I wonder if it's better to just remove it for now and re-add it later if we have a better use case.

I think more information/ discussion is needed on how/ if people use these endpoints already. I see the value of having "shortcut" data available so you don't have to call multiple endpoints every time (like GET /race -> GET /trait for each trait on the race just to know if the race gets any starting proficiencies), but these shortcut endpoints do introduce redundancy. Then you'd get into the classic normalized/de-normalized data argument, and you have to decide exactly which data gets de-normalized and where to stop.

I think my current PR's can just be merged back in their current state. Maybe after some discussion a decision can be reached on what to do with the /api/2014/races/:index/proficiencies and /api/2014/subraces/:index/proficiencies endpoints.