I realize that the API is frozen, hence tagging this as support rather than feature-request or bug - I'm irritated about the two routes /badges/name and /badges/tags:
- They seem to simply filter down what's available via /badges anyway? Aside from the option to filter /badges client side via a lookup for "tag_based" (as argued/suggested by Kevin for another case), the API is using query parameters rather than paths elsewhere for (simple) filter operations on a resource collection like this (and correctly so, from a RESTful perspective).
- Even if desired, 'name' is singular were 'tags' is plural, which seems odd to me (might as well be a non native speaker issue though ;)
Has this asymmetric design been chosen deliberately and are there any insights into the decision available in case? Am I missing a use case one should know about when using these routes?