Reimagining the static badge URLs
- Dominant language
- JavaScript
- Stars
- 27.2k
- Forks
- 5.6k
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 46
Description
The static badge URL is well established, yet quirky. It uses a nonstandard escaping practice which only exists in Shields. It's inconvenient to generate programmatically for just that reason.
@RedSparr0w made an effort a while back to create a new one using the query string: #1395. I think it's a nice idea to do that and that we _should_ do that using the schema for the endpoint badge, once that goes live #2495. That will support well the cases where badge URLs need to be generated in code.
Someone on Discord today was asking about a url like https://img.shields.io/badge/PyCalVer-v201901.0019--beta-blue.svg where the version sometimes has a suffix and sometimes doesn't, and thus sometimes but not always requires escaping. I'm checking if that is a programmatic case or a manual case.
We could also consider adding a version that uses the more traditional `/` separator, e.g. `/badge/:label?/:message/:color?` My only concern is about how to include slashes in the label and message. I'm not sure how to solve that. Maybe that case could fall back to either the query-string version or the legacy version.
Obviously we'll need to support the legacy version as well.
Contributor guide
Research direction
Start by reading the discussion in #1395 and the endpoint badge schema proposed in #2495. Compare the legacy static badge URL behavior with the query-string and slash-separated alternatives, especially labels or messages containing slashes. Done requires an agreed URL design that supports programmatic generation while preserving legacy URLs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100