Certainly, at YRS we found ourselves going (unknowingly) over a
project that had been tried before at the previous RS!
Although our app turned into more of a proof of concept (+ rail
timetable data scraped using an existing tool), I am looking to deveop
it further.
It also occured to me that there are many people working on National
Rail data who are not aware of RS, I'm trying to pull the ones I find
into a Google Group (currently a little inactive), that should help
pool resources and code - http://groups.google.com/group/nr-data
--
Regards,
Thomas Wood
(Edgemaster)
At YRS, SOAP was one of the evils we encountered with the national
rail departure boards API, their implementation of the server didn't
seem to want to work with the SOAPpy library I was trying to use
(probably incorrectly).
To save on headaches, we decided to move that aspect of the app to
'future work', and produce some fake data instead to demo it.
Ruby and SOAP isn't too hard, well at least sometimes:
http://planb.nicecupoftea.org/2009/03/12/companies-house-xml-and-rewired-state/#tech
Rob McKinnon's done some more in this area I think (he's on this list
I think).
Libby
> I've been invited to the Department of Health to advice on their new
> API, so if anyone has any comments about what an API should have
> (format, data, query method etc), drop me an email.
Please, no complex XML schemas, no big upfront design, no grand
interconnected visions.
Just readable documentation, example code and a support contact who
knows what they're talking about. For the best example, look at the
Flickr API. http://flickr.com/services/api/
I don't mind if it's REST, XML-RPC or whatever. As long as I can
understand how to get the data in and out without having to buy into
your grand software architecture or bespoke software, then that's fine.
--
Tom Taylor
t...@tomtaylor.co.uk
http://tomtaylor.co.uk
+44 (0)7811 249572