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.

this reminds me of the time I got on a train to Kingsley instead of King's Cross, because the train board only said "Kings" and I didn't think to check the boards/platform number in a rush.

Ahh, that's the worst. Hopefully you realized your mistake sooner rather than later.

only went one or two stops the wrong way and turned around. I was new to the British train system.

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?

For each person who is willing to speak up and say they don't understand something, there's usually dozens more who silently are wondering the same thing. Even if the parent commentor didn't want an explanation, they opened to floor for others to help out the silent folks who actually were curious as to the explanation.

So true. I have a rule of 100: for every person who takes the time and trouble to actively respond to something on the phone/by mail/online, there are 99 others who feel exactly the same way but can't be bothered.

Do you really think they're "mansplaining" to the user identified as bookofjoe?

Pretty sure they're all women.

What’s the harm? Parent can choose to not read if they want.

This made me smile.