Caching disruptions data

Unified API
1

I’m checking the api for Line/Stoppoint disruptions

    https://api.tfl.gov.uk/Line/102/Disruption
    https://api.tfl.gov.uk/StopPoint/940GZZLUOXC/Disruption

cache-control: public, must-revalidate, max-age=30, s-maxage=60

I wonder why the cache header in the response only 30 seconds. Are disruption data so volatile we have to request so often?

2

@albert

I think I can answer this. I’ve worked with TfL Rail and London Overground pushing status upgrades from their control room to public and there is a very clear need to push status messages - especially those associated with fire or suspected terrorism to the public directly.

For example, the declaration of a “CSL/2” or Service Close/Suspended where the public are required not to enter or to leave the station/train with immediate effect requires that the people effected know straight away.

I’m shocked it is as long as 30 second cache because this means there will be some people getting the wrong critical message for up to 59 seconds!

Also remember that this online status system is THE WAY that messages are passed to staff and contractors who work for TfL. All of the other display systems used to keep the public safe and informed use it.

1 Like
3

Thanks briantist,
Actually I was interested in less critical info i.e. the stop being closed or line diversion.

4

@albert

I guess that the point is that it’s always going to be a “push” message, because even if the status might last for … months, it might change with a literal seconds notice.

I keep meaning to poke the length of status messages like the TfL ones into an AI, so you might be able to predict how long an unexpected fault might last…