URL design
Currently, the API is available at the root, ie: https://datasets-server.huggingface.co/rows?...

This can lead to some issues:
- if we add other services, such as /doc or /search, the API will share the namespace with these other services. This means that we must take care of avoiding collisions between services and endpoints (I think it's OK), and that we cannot simply delegate a subroute to the `api` service (not really an issue either because we "just" have to treat all the other services first in the nginx config, then send the rest to the `api` service)
- version: if we break the API one day, we might want to serve two versions of the API, namely v1 and v2. Notes: 1. it's better not to break the API, 2. if we create a v2 API, we can still namespace it under /v2/, so: not really an issue

Which one do you prefer?

1. https://datasets-server.huggingface.co/  (current)
2. https://datasets-server.huggingface.co/api/
3. https://datasets-server.huggingface.co/api/v1/

URL design: Currently, the API is available at the root, ie: https://datasets-server.huggingface.co/rows?...

This can lead to some issues:
- if we add other services, such as /doc or /search, the API will share the namespace with these other services. This means that we must take care of avoiding collisions between services and endpoints (I think it's OK), and that we cannot simply delegate a subroute to the `api` service (not really an issue either because we "just" have to treat all the other services first in the nginx config, then send the rest to the `api` service)
- version: if we break the API one day, we might want to serve two versions of the API, namely v1 and v2. Notes: 1. it's better not to break the API, 2. if we create a v2 API, we can still namespace it under /v2/, so: not really an issue

Which one do you prefer?

1. https://datasets-server.huggingface.co/  (current)
2. https://datasets-server.huggingface.co/api/
3. https://datasets-server.huggingface.co/api/v1/
