Jannis R

> We could use something like this (perhaps with more appropriate key names, I just can't think of any right now). > > ```js > { > "endpoint": "/api1/train-position", >...

It just came to my mind that we could use [OpenAPI](https://oai.github.io/Documentation/) (whenever applicable) to document these APIs; It also splits an API spec into [*API Endpoints*](https://oai.github.io/Documentation/specification-paths.html) and [*API Servers*](https://oai.github.io/Documentation/specification-servers.html).

Technically, this is a breaking change, but AFAIK no one uses `transport-apis` yet.

I think doing this is helpful, if it's not too detailed. Validation or not, if we renamed `version` to `ver`, that would break clients depending on `ver`. This is why...

When we chatted before, I forgot to tell you that there are [community-maintained TypeScript typings](https://www.npmjs.com/package/@types/hafas-client), sorry. These may (have been) used to generate the JSON Schema definitions.

> Thinking about it again, we should have one common schema file for all endpoints. That way, it's easier to replace it with a new auto-generated version. And the reused...

> In case that didn't become clear, I was talking about the endpoints like journeys, departures, arrivals, etc., which in the first iteration have completely separate schemas. Yes, we can...

I finally found time and energy to look at this from a broader perspective. Thank you for waiting. Also, I'd like to cc @bergmannjg, who has contributed the `hafas-client` typings,...

Another unrelated note: @traines-source Since you opened the PR, I have updated `master` to contain the `v6` implementation of the API(s), doing some backwards-incompatible changes and upgrading to `hafas-client@6`. You...

I'm a bit hesitant to use tools like tsoa because they impose a very specific structure upon your API, which IMHO is neither more understandable (the controller pattern really doesn't...