API paths on run-config

Currently, the API is called with /api/service/ (For example api/overworld/config/minigame/).
According to our new API design, we want to implement a versioning in the path.
The overworld backend for example will have a new internal path of api/v1/. A request then points to api/v1/config/minigame.\

Now we need a new path scheme to implement the versions. Additionally, each API should have a new internal path of api/v1/.

Possible Solutions

  • /api/service/vX/

    • e. g. /api/overworld/v1/config/minigame/

  • /service/api/vX/

    • e. g. /overworld/api/v1/config/minigame/

  • /api/vX/service/

    • e. g. /api/v1/overworld/config/minigame/

Chosen Solution

  • /service/api/vX/

Pro / Contra Possible Solutions

  • /api/service/vX/

    • version is added but the scheme is a bit strange because we have the service between api and vX.

  • /service/api/vX/

    • version is added and the scheme is clear and understandable

  • /api/vX/service/

    • not feasible, because our service API’s could have different versions and so we could have multiple /api/vX/