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!

And the value is "2" 😂

That’s still excusable, there are platforms that are not numbers (2A, or just B etc)

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.