Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[API] Route: /version #1222

Open
kozabrada123 opened this issue Sep 27, 2024 · 0 comments
Open

[API] Route: /version #1222

kozabrada123 opened this issue Sep 27, 2024 · 0 comments

Comments

@kozabrada123
Copy link

kozabrada123 commented Sep 27, 2024

Is your feature request related to a problem? Please describe.
When developing an app meant to support several different Discord API implementations, sometimes on different versions, it would be very useful to be able to easily find the software you're working with and its version.

Why? Sometimes issues only arise only on one implementation, an implementation has extra features or a bug is found in an implementation. Even after bugs are fixed administrators do not update immediately and instances still run faulty versions. Knowing if you're working with a server on an affected version means the difference between your app working and crashing.

Describe the solution you'd like
A new route along the lines of /api/version, which returns the server's software (spacebar) and its version.

A return schema may look like this:

{
  "version": "0.2.1",
  "server": "spacebar"
}

(Other server implementations could then simply change the "server" field to identify themselves)

Describe alternatives you've considered

Why .well-known is not enough

As a convention, .well-known/spacebar does exist (though not always), but that doesn't expose the server version and is only available on the base url (http://spacebar.chat/.well-known/spacebar exists, but http://old.server.spacebar.chat/.well-known/spacebar or http://old.server.spacebar.chat/api/.well-known/spacebar do not - and apps may only have the api url, not the base url)

Other viable alternatives

  • Spacebar already has the route /api/ping, which could also be updated to add this version information
  • the route /api/policies/instance/ could also include this information

However, adding a new route is preferable to changing an existing one - this would break existing apps relying on the old schema and new apps expecting them to have the new fields on old instances

Additional context
This was also discussed in the spacebar guild, see https://discord.com/channels/806142446094385153/806142446529806367/1289269996404473959

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant