Provide an endpoint to create shields.io badges

[dnaka91]

Deps.rs already has its own badge but shields.io allows for a wider variety of themes and customizations. That service has an endpoint feature that gives the option to generate badges for systems that are not natively supported by them.

There are several additional features that can be defined in the data for the endpoint but for now I kept it simple and only provided the basic information that is equivalent to the self-generated badge.

The badge can be easily tested by using a service like ngrok:

https://img.shields.io/endpoint?url=<temp-ngrok-url>%2Fcrate%2Frand%2F0.8.4%2Fshieldsio.json

Currently I'm just not sure where to inform about this feature on the deps page, therefore I made this a draft.

[Icelk]

This is great!

Should we maybe provide data for all sub-crates and all the data, not just the message?
Then, an API can choose which data to display. Also, sub-crates could get a badge, something the badges of this repo don't support.

[Icelk]

I've opened a PR at badges/shields#7219 for an implementation on their side.

[dnaka91]

Hey thanks for letting me know. Almost forgot about this PR, haha 😅.
Having a direct implementation on their side would be much better of course. Let's see how it goes.

If they decide to not implement it, then just tell me what else you need on this PR and I'll get it added here.

[calebcartwright]

Should we maybe provide data for all sub-crates and all the data, not just the message?
Then, an API can choose which data to display. Also, sub-crates could get a badge, something the badges of this repo don't support.

Greetings from the Shields.io side of this equation 👋 Definitely want to echo and underscore this point. Our Endpoint badges are really intended to support use cases that need more power/programmable control atop our standard Dynamic badge offering. Think of it being more for individual use, and not what we want/are typically willing to utilize for our first-class/native badge offerings for services.

We have a very strong preference for consuming standard API surfaces that provide the raw data so that we can provide badges with defaults that are both consistent with our other offerings and adhere to our specification, while at the same time still supporting the configurability options. The Endpoint badge route dictates many of the rendering concerns (for good reason given its target pattern) which make it a very poor fit for native service badges.

A deps.rs json API that provides the raw, relevant dependency data would be a prerequisite for our ability to directly offer deps.rs based badges in Shields

[Zageron]

This gonna happen? 😂

[Icelk]

@dnaka91 Are you keen on implementing an API to get all the available data, in JSON format?

[dnaka91]

Ah sorry, I thought to wait on @Icelk to decide whether to create this API or not.
Sure, I can give it a try. Already did many web service projects in the past in Rust.

Not sure when I will start on this though.