The RTT API has long been a bit of a poor relation in the family of services that Realtime Trains offers. There’s been a large uptake recently in usage of the self service API portal and, since the new site launched, I’ve been thinking more about the direction to take the API. There’s been mention of this in updates over the last few months but it’s occurred to me in recent weeks I am not entirely clear about the right path to follow.
Before I continue any further, I should point out that there is a known backlog with access to the detailed mode of the API - which is entirely my fault and mostly linked to how little time I have right now. It requires a fair amount of fettling to get set up for each user and the detailed mode access itself is a bit fiddly. The next version of the API will be self service to access the detailed version.
With that in mind, I’d like to throw it out there for a bit of consultation as to why people use the API and where it should go. I would like to put together a small group of developers who will help the internal understanding as to where we are and where it should go. I will invite people to join that group based on who contributes to the questions below.
The questions are as follows:
- Why use the RTT API over other systems that are available?
- What are the strengths of using RTTs over others?
- What are its weaknesses?
- What is a challenge when integrating with the API?
- What do you think to the availability and reliability of the service?
- What should the RTT API be able to do that it doesn’t already?
Answers on a postcard email to datafeeds@realtimetrains.com please, by the end of July.
