FunFact: I have enjoyed HN for about 10 years even though I have NO IDEA what an API etc. is. A tribute to its welcoming big tent for non-techies like me who wouldn't know a dark pattern from dark matter.
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.
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.
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
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.