Officially, last Friday was Labor Day in many parts of the world, including Germany. But I just wanted to get this maintenance patch out the door that had seen so many delays over the past few weeks, so I got a little work done anyway 
Several people immediately spotted this line on the change log and inquired about it:
Closed preview of a first read-only API endpoint.
Regular readers will know that the API is a recurring theme on the devlogs ever since I started serious work on the gen-3 UI. The new frontend requires an API on the backend, so one can’t happen without the other. As such, the main driver here are the requirements of the new UI, not so much third-party consumers of the API. At the same time, sticking to common best practices and standards helps internal development as well. For example, having the API endpoints and resources defined in a standardised format allows to use ready-made tooling to generate an “SDK” that the client-side code can use to talk to the backend, reducing the time spent on writing boring boilerplate code quite drastically. But with these structures in place, there’s relatively little extra effort required to make the specs available to 3rd parties so they can talk to the API and generate their own client libraries in whatever language they prefer as well.
The first such “third party” is AS Route Map. @matth had inquired about a proper API ages ago and just like everything else around here, it took a very long time until I finally got around to it. With most of the missing pieces in place last week, I decided to finally build out one endpoint as an example for Matt and add the fields he requires, despite the game not currently requiring said endpoint.
To absolutely nobody’s surprise, merely “adding a few fields to an already existing endpoint” took considerably longer than I had anticipated. The reason being that seemingly trivial questions like “how should physical quantities be represented in responses?” require quite a bit of consideration when you design a general interface that will be accessible to yet unknown consumers in the future. And once a decision has been, it needs to be implemented in a way that ensures the structure, aka the interface, remains the same across all endpoints going forward so the developer experience is consistent and doesn’t violate the principle of least surprise too much.
Obviously, for any future endpoint, these things are going to go increasingly quicker. But in week 18, it took a while.