URI structure convention

[mrhyde]

I took a detailed look at current situation with URIs and i found some pretty weird conventions...
Lets take this link as example:
http://img.shields.io/gem/dtv/rails.svg
http://img.shields.io/github/release/qubyte/rubidium.svg
http://img.shields.io/github/issues/badges/shields.svg
but if you take a look at issues url in github you will found something like this:
https://github.com/badges/shields/issues
its a pretty standard format if you had experience with REST paradigm and i think following this convention would solve a lot of problems and make integration of news services easier.

Just take a look at this:
/github/badges/shields.svg - this can be a default badge, just for a sake of example
/github/badges/shields/issues.svg - issues
/github/badges/shields/tag.svg - tag
/github/badges/shields/release.svg - release
and you have it already with travis:
/travis/joyent/node.svg
/travis/joyent/node/master.svg
/travis/joyent/node/v0.6.svg
and in a case of gems, it makes even more sense:
/gem/rails/dtv.svg
/gem/rails/dt.svg
/gem/rails/dv.svg

Isn't it prettier?

My point here is that we need some general convention for naming instead of the mess we are having right now, and service/username/project/resource.svg is a very good candidate on my opinion.

[espadrine]

We obviously cannot break the current design, which has a lot of legacy parts to it itself.

Beyond that, even the design you suggest has issues.

• The example you use for Travis wasn't future-proof with David and Code Climate.
• Not all badges fit nicely in this "vendor / project / type of data" pattern. Trying to apply weird semantic rules quickly becomes inconsistent. Applying hierarchical rules does not.
• The number of datum needed by a vendor switch can vary based on the vendor switch, which means that the number of slashes in the middle suddenly counts in your design. For instance, /teamcity/bt428/codebetter/build.svg vs. /teamcity/bt428/teamcity.jetbrains.com/build.svg. Accidentally matching one for the other becomes a risk, yet making them share the URL matcher would be wrong since they have different treatments.

In short, yes, we have legacy formats. They're not a mess, even though they can't all fit nicely in a unique pattern. Each vendor has its own behaviour, and we have to adapt to that. Adapting to more and more specialized idioms in a left-to-right manner is what we have done. Changing halfway would only make the whole thing uglier, and potentially introduce damning issues.

I hope we can close this issue without a backlash on your part.