Add ability to version Scribe-Server's API and create v1

[andrewtavis]

Terms

• I have searched open and closed feature requests
• I agree to follow Scribe-Server's Code of Conduct

Description

In discussing the plans to use data contracts in the end Scribe applications, we made the decision that we need to version the Scribe-Server API to ensure that if contracts change such that we need to update the end applications, that we can then release a new version of the API such that those applications that are using the old system can still make API requests without needing to update the application. We don't want people to experience a broken process, but we will be adding alerts for people to update their application via issues in the end applications.

In this issue we will discuss and implement the versioning of the API and also change the endpoint such that it's on v1 :)

Contribution

Happy to discuss the solution here and assist as I can! 😊

[andrewtavis]

CC @wkyoshida and @axif0 :) It would be great if we could do some exploration and share findings in the issue and then we can make a plan on implementation from there 😊

[axif0]

I thing we can go for three api .

Stable API (v1/{iso_code}/): Updated only on stable releases (e.g., v1.0.0), triggered by Toolforge via GitHub Actions.
Beta API (v2/{iso_code}/): Updated on main branch pushes, for users in the beta program.
Development API (localhost:3000/{iso_code}/ we might need it to test the changes locally.

So, therefore if user joins beta program, we can set user's v2/{iso_code}/
if it is stable then it should v1/{iso_code}/

If user wish's to have beta release, like when the scribe-server or got updated, user immediately got the update. Using a bug report section in keyboard app with quick screen shot or joining metrix channel, he can report us.

(optional) If we want to have a bug report section we might need a light weighted frontend interface to see them.

Ref: Toolforge/Auto-update a tool from GitHub/GitLab