# 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/`