Help users avoid Endpoint-Badge-Caveats... (github gist)

[nocke]

Hi,

just something I encountered in practice, could be worthwhile for the

Endpoint Badge Docs Page / Link-Creator

1. one might wonder, where to put his state / host that json, sure plenty of microservices around, but a simple and effective way is (for low-frequency status change like "most recent release" might be github gists.

(gpt send me in all the wrong direction before I caught this simple approach :D )

→ could be added as a suggestion?

my use of this in a CI/CD-pipeline is here

2. if someone does gists, you already rightfully block access for those who accidently use the web view (and not, -correctly- the raw view of that json)

There is another rather evil thing (imho) by default one easily has a link to the specific version of that gist at hand, well, when you go for raw view and just take that URL. Turns out, one has to take out a portion (Stackoverflow Link) to always reference the latest state of that gist.

→ shoud be noted as a caveat.

almost certainly not what you want (fixed reference to some version)
https://gist.githubusercontent.com/[gist username]/[gist ID]/raw/[gist commit ID]/[file name]
                            ↓
almost certainly what you want (reference to latest, current (test-/release-/whatever-) state)
https://gist.githubusercontent.com/[gist username]/[gist ID]/raw/[file name]

Technically, the Link-Generator in the could could churn out warnings, if certain regExps are met?

"regExp non-raw-ish github URL" => "warning text on that....",
"gist URL, that still contains a commit ID (hardly what you want)" => ...

This could be easily expandable then. If more common caveats come along...