Thank you in advance.
https://api.tfl.gov.uk/line/mode/bus
would you believe it!
https://api.tfl.gov.uk/swagger/ui/index.html?url=/swagger/docs/v1#!/Line/Line_GetByMode
1 Like
The 2nd Url wasn’t working for the past two days. I thought maybe there was another one. Back on now! Thank you again.
1 Like
I guess that will be down to @jamesevans sorting it out.
Personally, I’ve never gotten the Swagger system to work as an API tester, but I do have Adblocker Ultimate installed…
Hi @Kupod5uR
The Swagger doc generation is pretty flaky and for some reason puts incorrect domains in the “try me” responses when we deploy updates to the API.
We are going to deprecate it in the near future, so I would suggest using the new interface at
This is updated with newer API endpoints as they are released (e.g. crowding, lift disruptions), not just the “classic” endpoints that are in the swagger interface.
Thanks,
James
1 Like
In that new list I see this:
That’s not very helpful, is it 
Could they be made to wrap on to a second line, rather than be truncated at places that make them difficult to understand?
Alternatively, provide a “short form” such as
- Stop points reachable from statioin/line
- Arrival/departure predictions at stop point
- Arrival predictions at stop point
- etc
Can’t you see the information when you click on? I see this
I can, but only one item at a time. And it’s often not possible to reliably guess which specific item to click on before clicking on it to find out whether it’s the right item to click on.
And then we have these two:
So we have a list which, apparently, contains two identical items – guess how many times I have to click on each of them before being able to spot what the difference is. OK, bad example perhaps. But if they weren’t truncated, maybe somebody would have spotted that the same item is there twice without having to click 5 times on it to try to work out the difference.
My point is … why is it necessary to present it in such an unnecessarily user-hostile manner? It’s not the way a competent technical author would choose to present it
Fair point. I wouldn’t do it this way. I think it might be the output of a API generation tool. As I had to write up some APIs I had written for my client a month or so ago I looked at a few of the products and rejected them in favour of a Word document…
It’s a bit of a shame that @jamesevans isn’t doing as you suggest as the TfL API as actually well thought out, very capable, very fast and logically arranged (well mostly!).
The TfGM API is good comparison. The docs are there, but missing out on what output you get! Open Data Portal | Bee Network | Powered by TfGM? -
otherwise you would know that you have to write pages of code to work which is the “Blue Line”
TfL has the data and it’s quite comprehensible.
1 Like
There’s some very weird formatting going on. If I reduce my browser to approx. an eighth of my screen width the page displays MORE text!
compared with:
and going full screen…
Taking this (text-truncate) out works wonders 
Simon
1 Like
It does indeed. And in firefox with the Stylus addon I can simulate that by adding the CSS:
.operation-name { white-space: normal; }
But being slightly fussy, that means the list for some categories exceeds the screen height. So to keep it neat and tidy I also add a couple of scrollbars:
.nav { overflow-y: auto; display: block; max-height: 50vh; }
.ycqdvmhchp { overflow-y: auto; display: block; max-height: 75vh; }
The result:
The values 50vh and 75vh work for my screen, but would need to be different for other screen sizes. So to make it suitable for everybody, those values would need to be be replaced by a calc() or some other means of subtracting the height of the header from the screen height.
Sadly, although I can construct a calc() to perform the actual calculation, my css isn’t up to finding the height of the header element.
1 Like