Breaking changes we'd like to see

[Gredelston]

Someday in the future (post-#145), we may be able to introduce breaking changes to our data model. What are some breaking changes you would like to see? I'll start.

• Remove the stringy Montser.challenge_rating field, since it's redundant with the more useful numeric cr field
• Turn Spell.ritual from a string ("yes"/"no") into a bool

[eepMoody]

Remove proficiency/skill levels from the root of the monster response, and into a "proficiencies" object.

[augustjohnson]

For Spell.Ritual what about adding a new field?
As far as I can tell, we either don't have bools, or display them as text within our API. Other examples of potential bool fields:
"hover" (on a monster.speed). - currently has "true" as a value if they can hover, otherwise does not exist.
"requires_attunement" (on magicitems). - currently is either an empty string or the string "requires attunement" as a value. lol.
My suggestions (new fields):
spell.is_ritual [BOOL]
monster.speed.can_hover [BOOL]
Technically a breaking change but I can't imagine it would actually break anything because the data in the field was so bad.
magicitem.requires_attunement [BOOL]

@eepMoody I agree that the move of ability stats into an object would be more intuitive.
Another along this same line: monster.senses should be machine readable, similar to movement. Condition immunities as well.

Here are some examples of potentially breaking changes that I could maybe get behind.

1. Separate endpoints between "Monsters" and "NPCs". It's hard to say "Noble" is a monster, and even the SRD differentiates.
2. New /items endpoint that included Armor, Magic Items, Weapons, etc as sub-resources. - This might not have to be breaking, but the whole API gets weird if there's a /items/armor AND a /armor endpoints both at once.
3. A document in the URL means you're filtered to just that document. i.e. /tob3/monsters would result in JUST those monsters. Also, not necessarily breaking, but awkward at a minimum.
4. I suppose the extremely machine-readable monster stats would be useful. Vulnerabilities is a list, immunities is a list, languages is a list, etc. This could go into some sort of "character" model, whether it's an NPC or a PC or a Monster, and those endpoints could be presented nicely.

Maybe there's some data models that can be combined? Spells / Actions seems like it could be approximately combined? Items could include Armor, Weapons, MagicItems, etc. Characters could be NPCs, Monsters, etc? That might be over-optimizing though.

[Sturlen]

I'd like to see proficiencies, skills and languages split into a more machine-readable list format instead of the current concatenated strings.
e.g. ["Strength", "Dexterity"] instead of "Strength and Dexterity".

Having consistent fields that concatenate data, as well as the underlying structure would also be nice. Currently the style seems to be variable for the raw data and variable_desc for the concatinated version, but this is not applied everywhere.

[augustjohnson]

if you're noodling on where to start with a v2, I'd strongly suggest spells. It's complex, but not TOO complex, and has a couple of those 2 layer deep fields that aren't well represented today. A lot of the decisions made in speccing that out would set good precedents for the tough one, monsters.

And an upgraded spells UI on open5e.com could be a good consumer.
Filter spells by damage type?
Sort spells by casting time? - These are important features.