Draft-commit of materials data structure

[Marvellanius]

So this weekend I didn't find the time to work on this, but found some time today.

This is clearly a draft, with incomplete data to facilitate concrete discussion about the preferred structure for the materials data.

The proposed way should still conform to the currently defined routes, so no changes to those are necessary, which I figured was preferable.

Yeah not much else to say, I think the changes speak for themselves, but please name anything that could be improved regarding structure, naming of keys, etc.

By the way, I chose to use incomplete data to convey the idea of the structure, naturally when a final structure is decided, I'll fill in the missing data

[JMPJNS]

should we add which characters/weapons use the materials?

[NurMarvin]

should we add which characters/weapons use the materials?

that would be pretty nice, yeah, though I'm unsure how much work that would be

[Marvellanius]

Possibly, could add related characters and weapons to relevant items (e.g. characters: [], weapons: []). what I've been wondering is how we'd do the linking. We could either drop in the full name (which would be less preferred imho for accessing it programmatically), or drop in the 'slug' -as I like to call it- in this case, the foldername (e.g. 'albedo' instead of 'Albedo').

Now to make consuming the API easier for rendering purposes we could also choose to go with an array of objects: characters:[{name: "Albedo", slug: "albedo"}, {name: "Diona", slug: "diona"}] but to be fair, I would only do this to reduce API requests, and since all of the responses get cached anyway, that might not be a concern. So my preferred way of 'linking' would probably go to using the slug for characters and weapons