Post

A thread 🧵 of _terrible_ design decisions for the internal APIs of the two Italian high speed train operators, Italo and Trenitalia. Hardcoded passwords, terrible translations, spelling mistakes, xml in json (but utf8 encoded and transmitted as an array of numbers), it's all here. Enjoy!

Italo's app sends a "Login" request on startup with a hardcoded username and password, which coincidentially also is entirely unnecessary, because the data it fetches with the returned data is available without authentication!

Trenitalia's internal API for getting the real-time travel info for a train has a beautiful translation error: the platform identifier field is called `binary`, because in Italian, platform is "binario".

This endpoint has another great design choice: the departure and arrival data is stored in two arrays with fields with a description of either "Scheduled departure", "Actual Departure", "Scheduled Arrival", or "Actual Arrival". Note the capitalization difference between "departure" and "arrival".

On startup, the Italo app also fetches a list of all stations Italo can sell tickets to/from. This file is 2.3 MB, but not because of the list of stations. No, it's because it contains for every station, the list of every other station that is reachable from that station (and much more garbage)

In a suprise to absolutely no one, the API the Italo app uses for real-time data is also beautifully designed. The disruption field has the great name "Distruption", and the dates are encoded as strings in the format "\/Date(1766949300000+0100)\/". Note those backslashes are not escaping anything.

On startup, the Italo app also fetches a various XML encoded bits of content from it's CDN that it uses to display ads and such on the index page. This XML is UTF-8 encoded, and then sent as a JSON array of integers in the range 0-255. This increases transfer size by slightly over 3.5x!