fix API routes case differences

[sebadob]

fixes #536

• tokenInfo -> introspect (done in PR #534 )
• rotateJwk -> rotate_jwk

Since I don't like kebab-case, most API routes are written in snake_case, with 2 exceptions that follow RFC namings:

• openid-configuration
• web-identity

All the *info routes are not kebab_case on purpose, just to match other IdPs and RFC a bit more.

There is not a single camelCase anymore in the API routes to avoid confusion and issues in situations where you could mistake an uppercase I as a lowercase l. The current camelCase endpoints only exist for a smoother migration and will be phased out with the next bigger release.

[polarathene]

Since I don't like kebab-case, most API routes are written in snake_case

While I understand preference, isn't kebab-case the convention for URLs? How often do you see snake_case in the wild?

EDIT: Seems there are some big names that have snake_case (although they've retained that for over a decade so it could be legacy 🤷‍♂️ )

• Dropbox
• Twitter / X

Many do use kebab-case though: https://blog.stoplight.io/consistent-api-urls-with-openapi-and-style-guides

UX wise, minor improvement for typing with - (lowercase) vs _ (effectively uppercase due to requiring shift?), not that it matters much since this is an API 😅

---

Don't mind me though, I'm good with whatever you're comfortable with, just glad that it's consistent and no mixed casing 👍

[sebadob]

I don't think that there is some convention, and if so, it probably changes all the time anyway.

The only problem were the camelCase routes. It's not about "how hard is it to type", but more about avoiding confusion. In the past, I had many cases where customers were using an existing API with camelCase routes, and they often read characters wrong, like for instance the mentioned l vs I or 0 vs O. In many fonts it's hard to tell a difference between them, if you don't look closely.