More API data in less network data
Days are getting shorter, and iRail API responses are getting longer. We’ve added some more data to various API endpoints, so you can build even better applications. We’ve also improved support for HTTP caching, and are closing in on a release for LinkedConnections. Let’s check it out!
Route data
For a while, we weren’t able to provide the status for trains in a connection. We didn’t have that data, and we were at peace with it. But everything changed when the NMBS decided to delete a file from their site. Our status monitoring told us we were in trouble a minute or two later. It was the endpoint we were using to query connections, and now that it’s gone, we had to get our data somewhere else. With tens of thousands daily API requests, we’d also better fix it fast. I continued a previous investigation into the NMBS mobile app API. Quickly I was able to figure out how it worked, and we were able to get the API back online within 4 hours and 19 minutes. Within a few days the new code was mostly bug-free, and any bugs in the last weeks were quickly fixed, thanks to the help of some other developers who were happy to assist.
With this bad news also came some good news. While the old endpoint didn’t provide data about trains arriving and leaving the next station in your route, the new one does. Therefore, we are now able to provide you with the left and arrived status of trains in a connection. Make something beautiful with it.
Example usage of the left and arrived attributes in the open-source Hyperrail application
Example usage of the walking parameter
We also have alert data, pin-pointed to specific parts of the route. This way end-users can be even better informed about where in their journey they can come across some hinder. In order to demonstrate what’s possible with this new data, I’ve taken some screenshots using the Hyperrail for Android application which is already update to use these parameters.
Example display of alerts
Last but not least, there can now be walking parts in a route. This is rare, but in some cases it’s necessary, for example when travelers get off at Haren but need a next train at Haren-zuid, which is within walking distance, without any trains connecting those two stations.For the techies: a new attribute ‘isWalking’ has been added to every departure/arrival of a connections object. This way you can easily distinguish those routes. Just don’t try to parse a train or destination for those walking parts, but you can read all that in our documentation.
Vehicle data
I’ll keep it short here: You can now see if a stop is part of the ‘normal’ route of this train, or if it’s an extra stop which was added last minute by traffic control.
Log and feedback data
All iRail API log data, and spitsgids feedback, is now automatically published on gtfs.irail.be every morning at 3:00. This way everyone can instantly make use of the most recent spitsgids data. Feel free to scrape this site if you need data for multiple days. The formats are documented in the API documentation.
Conditional get requests
A 304 Not Modified response signals you can just keep using the last data you have
The API supports caching and conditional get requests. Conditional get requests allow you to tell the server which version of the data you have. If there is newer data available, the server will return an HTTP 200 status code along with the new data. If no new data is available, the server will return an HTTP 304 Not Modified status code, along with an empty body. We only support the if-none-match header for now, with more details in the docs.
What’s next
Having all these new fields doesn’t mean we’re done here. We’ve almost gotten LinkedConnections ready for production, and we’ll be opening up a lot of data about stations and their accessibility. Make sure to follow @iRail on twitter to stay up to date!
You can read all of this over in the documentation, view the iRail API code on github, or view my Hyperrail source code on github. View our data dumps at gtfs.irail.be.
Comments (2)