Merge Spellcasting, StartingEquipment, and Class Levels into Class objects.

[fergcb]

Currently, the 1:1 relationships of Class->Spellcasting and Class->StartingEquipment exist in the schema as URL strings, rather than the data simply being embedded in the Class object. This only serves to reduce the size of the Class endpoint response, but complicates the digestion of the data rather a lot. Having separate endpoints for Spellcasting and StartingEquipment also creates difficulty maintaining consistency in the structure of internal references; where all other references are suited to using the APIResource structure, these are simply incompatible due to the shape of the referenced data.

As for Class Levels, the size cost of including all Level data in the class resource is much greater than for Spellcasting or StartingEquipment. It would perhaps be more suitable, however, to provide references to class levels as an array of APIResources, rather than the current method of supplying a URL that returns such a list. This would again simplify the digestion of the API data greatly, including by reducing the number of API calls that have to be made. Additionally, leaving the Levels endpoint intact allows levels to be queried separately from Classes, if desired.

In summary:

• Merge Spellcasting and StartingEquipment data directly into Class objects, get rid of corresponding API endpoints
• Provide Class Levels as an array of APIResources in the Class object, keeping Levels endpoint

All of this can be applied to Subclasses, also.

Another one to discuss is class Spell lists. Move them into Spellcasting, or directly onto the Class object, as an array of APIResources, like Levels?

[bagelbits]

Spellcasting is now merged.

[bagelbits]

All of this can be applied to Subclasses, also.

I would leave subclasses as is. Mainly because you can have more than one subclass, and it would break things for anyone that adds any additional subclass for their own DB. Or if more subclasses ever get released for OGL.

[fergcb]

@bagelbits that's not what I meant by that comment. I don't mean that subclasses should be merged into classes like levels, starting equipment, etc.

I mean that subclass levels could be merged into subclass documents as arrays (and any other 1-1 relationships), in the same way I proposed for classes.

[bagelbits]

Oh! My mistake! That makes a lot of sense!