Best part of 20 years ago, which is a long time in anything, it's a lifetime in tech. About 15 years ago I used to work on some projects for greater London authority, we seemed to mostly be squatting on transport for London servers and they seemed to have good tech and people seemed to like using it. 5 years later they couldn't get away fast enough.

For some reason I'm thinking of the classic "Speed cooking" videos:

https://youtu.be/8TVpQiCIqp4

If you're curious: An API is more or less just the communication boundary between two pieces of software.

A common sign of a bad API (including this one) is when it presents data in an overly human-centric way rather than something more computer-friendly.

For a human it's really easy to see "Regents Park" and "Regent's Park" are very very likely referring to the same station, but a computer can't know that unless a human goes out of their way to tell it that.

You could argue the TfL API is perfectly fine for its intended use-case of updating the arrival screens (which are meant for humans), but it's generally better to design APIs to grow for future use-cases you haven't thought of yet. Changing an API tends to be hard once it's being used in the real world.

For example: The older TfL stations have LED matrix displays for displaying information, which are very limited in how much text they can display at once. The newer stations have big TV screens instead, which can show a lot of information. It wouldn't surprise me if this is the underlying reason behind some of the inconsistencies, especially ones like "Kings Cross" vs "King's Cross St. Pancras". I'd bet the longer names with punctuation correspond to arrival displays in the newer stations.

An Application Programming Interface provides data to a requester. They are built/shaped by the provider and so the provider usually has documentation for a user to know how to pull and parse it, with example snippets.

Its like having a printer with preset documents it can print. You set it on your desk, and others can click a button to have the chosen preset sheet come out. You can get creative by hiding some buttons, making some buttons also require a fingerprint of the user to print the paper, or the printout changes every minute, etc.

But the API printer sits on someone's server and prints objects, or organized data, and sends it to whatever you used to call, or request, from the API.

It's like a website but for code instead of people.

People use web browsers to hit websites, but when code hits URLs they are typically just called APIs. A website is technically an API too

To the gloriously mansplaining sibling commenters: Do you really think a question has been asked in the parent comment? If you do, why?

I'll try and explain it simply with no technical information.

An API, or Application Programming Interface, allows you to interact with software using pre-defined agreements, or contracts.

Think of API as a set of legal contracts. I use this analogy when explaining it to lawyers.

If I give you $5, and I say give me an Apple, you will give me an Apple, as expected by the predefined contract, that I receive an Apple.

If I end up receiving Broccoli, then what we have here, is a bug. Or, in other words, the contract has been broken.

Now apply this to other domains in commerce - e.g. I give an ID of an item in a store, and I get back the name of the item, it's price, and if it's stock.

Seems to be: "TfL’s efforts to deal with the cyber attack have resulted in a growing shutdown of its own systems, meaning that new zip cards used by children and teenagers cannot be obtained" "17-year-old male has been arrested on suspicion of Computer Misuse Act offences in relation to the attack. The teenager, who was arrested in Walsall ..." https://www.standard.co.uk/news/london/tfl-cyber-attack-pers...

But its after the last trains now so not much to see.

I’m French and this is the first time I hear about it.