opt out of singularized id's.

[stephen-bartell]

Instead of singularizing the ids off the url, could we opt in to always expect id, subId, etc.

ie:

/people/{id}/skills/{subId}

vs.

/people/{person_id}/skills/{skill_id}

[dacbd]

I think its a good idea, feel free to send a Pull request, not sure how much free time we have to add this in quickly.

[nlf]

What if I exposed a parameter that allows you to override the name for the id? Something like..

users: {
  id: 'id',
  handler: // blah blah
}

Would yield the route

/users/{id}

[nlf]

That does still leave some complications for sub ids though.. Not sure of a clean way around that..

[joshua-mcginnis]

Just throwing ideas against the wall. You could have a mudskipper pack config option to disable singularization at which point id's could become :id, :sub_id, :sub_sub_id (or whatevs).

[stephen-bartell]

@nlf , what about @joshuamcguinnis's idea? I feel like prepending the id with `sub` would be a clean, deterministic approach.

Or you could just commit to using id and sub_id only, and tell everyone that if their resources go deeper that they're building it wrong. totally kidding.

[nlf]

Yeah, I'll have to account for keeping track of how deep I am in the nested routes during the refactor. Currently it doesn't track, so I'd have no idea how many sub_ strings to prepend. This kind of makes me wish that Hapi allowed you to use the same path parameter multiple times and just resolved it to an array..

/stuff/{id}/otherstuff/{id}

request.params.id = ['id1', 'id2'];

Maybe I'll have to look into sending that as a pull request..

[nlf]

pushed to the refactor branch. you can now pass uniqueIds: false as a top level object and it'll create {id}, {sub_id}, {sub_sub_id} etc

doing some more testing before merging that branch into master