@Jackymancs4 here are my thoughts:

• The only real "resources" we have are an avatar, identified by /:id, a custom avatar, identified by /face, and some meta stuff that doesn't really belong elsewhere
• I think everything else is a modification of the above, e.g. size or face components
• I think we should condense this down to three endpoints with optional query parameters:
  • /:id, with optional size parameter
  • /custom, with optional size and default components that can be overridden by specifying a query param (e.g. /custom?eyes=eyes1)
  • /meta for list and random, with an optional size parameter

The change to include the resultant size in /list seems fine to me.

I notice that on your homepage you say "we'd love to feature more artists' series."
To me, this implies there will be room in the future for expansion. This means you should include some space in your schema to allow for this.

I feel that the :scope should be included as a way of future-proofing, so you can add more sets later (for example, say I created a set that I called 'monkey faces.' This could easily be added, then, by using the scope monkey, making the full URL for an identifier-based monkey face something like /avatars/monkey/[email protected] with an optional :size parameter, or other params in place of the id, of course.

@brandonmack111 I agree!

So perhaps we need four top-level resources, then:

• /custom as above
• /meta as above
• /series/:seriesName/:id for artists' sets
• /:id as the backwards-compatible catchall

You might also want to allow custom avatars in other sets, perhaps with /series/:seriesName/:custom/<params> - though that does mean you need a modification to your /meta/list as well, since different sets will have different resources in them. That could perhaps also have an optional :series param (as in /meta/list/:series)

I'm considering working on this one myself, since I actually want to put together a set for you, and this would need to be sorted out first.

@brandonmack111 I think that there's a compromise between what is possible and what we can support as maintainers. Generating custom (not generated from an :id) avatars is not currently the core use case of this middleware. Custom avatars for arbitrary avatars series could exponentially grow the complexity here if not handled correctly.

I see one valid use case for the custom avatars: it allows clients the ability to override the hashing mechanism implemented by the middleware. If we instead make that piece of the codebase more modular and extensible, I would prefer that route to some arbitrary number of hardcoded endpoints.

@brandonmack111 something like this:

var Avatars = require('adorable-avatars');
var avatarsMiddleware = Avatars({ hashFunction: myHashingFunction });

var myApp = express();
myApp.use('/myAvatars', avatarsMiddleware)

Or just API versioning