Here's my biggest problem with doing more customizable dice: representation.
Let's assume I keep d8s-only with preset faces. This is what an API response would look like with that format:
{ "total": 8, "data": [ { "content_id": "PDdAaCF6", "name": "Purple", "slug": "Purple", "label": "Purple", "status": "PUBLIC", "canonicity": "COMMUNITY", "creator_id": "X5XZbkv5", "creator_name": "FoaS", "created_dtm": "2018-02-26 20:25:39", "editor_id": "X5XZbkv5", "editor_name": "FoaS", "edited_dtm": "2018-02-26 20:25:39", "genre_id": "PhKc35a9", "range_close": 1, "range_medium": 1, "range_long": 0, "face1": "b", "face2": "b", "face3": "h", "face4": "h", "face5": "c", "face6": "c", "face7": "hh", "face8": "ch", "color_body": "#cc55cc", "color_face": "#ffffff" }, ... ]
As you can see, all the data to show what a custom die looks like is represented in that response.
The problem is that if I allow for custom die-faces (other than hit, crit, acc, or some combination thereof) as well as a custom number of die faces (d4, d6, etc) then I lose a lot of possibilities as to what I can represent in the GET call. I'd have to iterate through all dice in the query, which could be a lot, and match up N-number of face components on each die. That's a huge performance hit - no good.
I could do "faceN": "(ID of dieface)", but that won't actually tell you what the die face means without doing a second query anyways - a big disadvantage.
I could pass a Thumbnail link in the body, but that becomes a problem for when there is anywhere from 4 to 20 faces - That's a big variation in data to represent in a 128x128 image.
Edited by FoaS