5 ms·

BART - The Real BART API (beta)

38 points by madh 17y ago

wallflower 17y ago
The irony about BART is I once randomly met the guy who does their software (.Net). He doesn't even use BART; he works from his office in Portland, OR!
kez 17y ago
Let the race for the iPhone app commence!
supahfly_remix 17y ago
That's a surprisingly open approach from a governmental agency. Most similar efforts seem half-hearted at best. I wonder what makes them different.
- pmjordan 17y ago
  All it takes is one enlightened person who is persistent enough.
- dnsworks 17y ago
  Massive budget deficits, gross mis-management, fraud, MURDER, etc have all come together to ruin BART's reputation and make them an embarrassment to California government. This is just another attempt at fixing their ruined image until the next scandal.
- pvg 17y ago
  Probably most of the credit goes to the people involved in the project and their ability to champion their cause and provide these services, straightforward documentation that looks like it's written for humans by humans, etc. Another part of it might be that BART has been highly automated and computerized since its design and inception so the data they offer has been available in some machine format or another for a long time. I remember there were a couple Macs with atrocious screen burn-in displaying all sorts of real-time info from the inside of the Berkeley Shattuck Ave Station Agent's fish-bowl in the early 90s - if you could hook it up to a Mac then, it seems natural you can offer it over the Web today.
  - madh 17y ago
    BART is definitely very automated. The 'drivers' don't drive; they mostly operate the doors. I've noticed that over the past year+ that BART has become very cognizant of current technologies. They are surprising active online: - Twitter (http://twitter.com/sfbart http://twitter.com/sfbart) - Posterous (http://sfbart.posterous.com/ http://sfbart.posterous.com/) - Facebook (http://www.facebook.com/bartsf http://www.facebook.com/bartsf) - FriendFeed (http://friendfeed.com/sfbart http://friendfeed.com/sfbart) Whoever is running the show is doing a great job.
csytan 17y ago
I'm always surprised when new APIs are released using XML. JSON is easier to produce and consume, so why's it taking so long to become standard?
- ionfish 17y ago
  Because XML is enterprise.
- thibaut_barrere 17y ago
  A large part of the developers I know (ie met physically) are not even aware of what JSON is (although it definitely contrasts with the web/ruby/python/javascript world). Another point is that API to parse XML are built-in (and widely known) in almost all platforms, whereas JSON requires external libraries on some (I believe .Net, Java for instance).
  - pvg 17y ago
    I think that's exactly it - XML integration, serialization to XML tends to be built-in to many existing environments. If the BART site is any clue, they are using ASPX/.NET. The XML they are using is also very straightforward, elements-only, no attributes, namespaces, SOAP, other weirdness. It doesn't look any harder or easier to produce and consume than JSON. For part of their previous offering they are using a Google-designed format called GTFS which seems to be essentially well-defined CSV.
  - IgorPartola 17y ago
    Encoding JSON is very easy. If that's all you are doing (e.g. only sending data to the client through say a web API), and you don't have a native library: build one. Edit: also, I am a big fan of providing both. It can be done simply and cleanly, so why not.
- Confusion 17y ago
  Namespaces are a good idea. Having both attributes and child elements is a good idea. The combination of those two allows for easy, partial, versioning of your schema. The ability to impose an ordering is also a nice idea. http://confusion.tweakblogs.net/blog/816/json-to-xml-conversion.html http://confusion.tweakblogs.net/blog/816/json-to-xml-convers...
dnsworks 17y ago
I'm assuming that there's a set of functions for shooting innocent but rowdy civilians in the back, while they're handcuffed and on the ground face-down?

38 points by madh 17y ago

The irony about BART is I once randomly met the guy who does their software (.Net). He doesn't even use BART; he works from his office in Portland, OR!

kez 17y ago

Let the race for the iPhone app commence!

supahfly_remix 17y ago

That's a surprisingly open approach from a governmental agency. Most similar efforts seem half-hearted at best. I wonder what makes them different.

pmjordan 17y ago
All it takes is one enlightened person who is persistent enough.
dnsworks 17y ago
Massive budget deficits, gross mis-management, fraud, MURDER, etc have all come together to ruin BART's reputation and make them an embarrassment to California government. This is just another attempt at fixing their ruined image until the next scandal.
pvg 17y ago
Probably most of the credit goes to the people involved in the project and their ability to champion their cause and provide these services, straightforward documentation that looks like it's written for humans by humans, etc. Another part of it might be that BART has been highly automated and computerized since its design and inception so the data they offer has been available in some machine format or another for a long time. I remember there were a couple Macs with atrocious screen burn-in displaying all sorts of real-time info from the inside of the Berkeley Shattuck Ave Station Agent's fish-bowl in the early 90s - if you could hook it up to a Mac then, it seems natural you can offer it over the Web today.
- madh 17y ago
  BART is definitely very automated. The 'drivers' don't drive; they mostly operate the doors. I've noticed that over the past year+ that BART has become very cognizant of current technologies. They are surprising active online: - Twitter (http://twitter.com/sfbart http://twitter.com/sfbart) - Posterous (http://sfbart.posterous.com/ http://sfbart.posterous.com/) - Facebook (http://www.facebook.com/bartsf http://www.facebook.com/bartsf) - FriendFeed (http://friendfeed.com/sfbart http://friendfeed.com/sfbart) Whoever is running the show is doing a great job.

csytan 17y ago

I'm always surprised when new APIs are released using XML. JSON is easier to produce and consume, so why's it taking so long to become standard?

ionfish 17y ago
Because XML is enterprise.
thibaut_barrere 17y ago
A large part of the developers I know (ie met physically) are not even aware of what JSON is (although it definitely contrasts with the web/ruby/python/javascript world). Another point is that API to parse XML are built-in (and widely known) in almost all platforms, whereas JSON requires external libraries on some (I believe .Net, Java for instance).
- pvg 17y ago
  I think that's exactly it - XML integration, serialization to XML tends to be built-in to many existing environments. If the BART site is any clue, they are using ASPX/.NET. The XML they are using is also very straightforward, elements-only, no attributes, namespaces, SOAP, other weirdness. It doesn't look any harder or easier to produce and consume than JSON. For part of their previous offering they are using a Google-designed format called GTFS which seems to be essentially well-defined CSV.
- IgorPartola 17y ago
  Encoding JSON is very easy. If that's all you are doing (e.g. only sending data to the client through say a web API), and you don't have a native library: build one. Edit: also, I am a big fan of providing both. It can be done simply and cleanly, so why not.
Confusion 17y ago
Namespaces are a good idea. Having both attributes and child elements is a good idea. The combination of those two allows for easy, partial, versioning of your schema. The ability to impose an ordering is also a nice idea. http://confusion.tweakblogs.net/blog/816/json-to-xml-conversion.html http://confusion.tweakblogs.net/blog/816/json-to-xml-convers...

dnsworks 17y ago

I'm assuming that there's a set of functions for shooting innocent but rowdy civilians in the back, while they're handcuffed and on the ground face-down?