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!

31 reposts177 likes

I hate to say it but this is how the school system teaches new IT/programmer technicians to write websites / documentation in Poland... yup, just write a PDF 😭

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)

This explains a lot of how it's borderline impossible to buy international train tickets online in Europe. The EU even gave them a deadline to do it themselves, because they thought it would be preferable to passing a law mandating it. The sailed right through the deadline with little to no change.

Hot take: the software that comes from taxpayers money or provides a public service should be open source. Both for transparency, but especially to allow us to fix these shitty designs πŸ˜…

Is it valid XML and JSON at least? I integrated with a transport API many years ago that was XML wrapped in some ancient invalid HTML 3 – only way to reasonably extract anything from it was to go crazy with regexp, at least that was my approach back then

Also reminds me of how often people forget to escape </script> tags when they stringify data to JSON for inclusion in HTML – mixing formats like that is sure to create some oversights and mess