The request is simple

  • Implement the OData API for Stack Overflow sites


  • It's a standard API.
  • OData allows the Stack Overflow database to be queried and navigated for questions, users, answers by using any attribute of those entities.
  • 5
    I'm considering OData for my StackQL redesign Mar 25 '10 at 16:30
  • 35
    cough hanselman.com/blog/… cough Mar 28 '10 at 17:39
  • 2
    @scott, post that as an answer!
    – juan
    Mar 28 '10 at 23:31
  • 2
    It has been said by many that StackOverflow is the community generated MSDN library, and with this capability... The MSDN library could be presented as a mashup with StackOverflow questions and answers
    – Jeff Fritz
    Mar 29 '10 at 2:38
  • 3
    Joel - Let's talk, perhaps we can work together. I need help convincing Jeff, he just doesn't see the value in OData at all. Mar 29 '10 at 3:25
  • I'm a .NET junkie .. but is there a Ruby on Rails SDK thingy .. for my ruby friends to consume?
    – Pure.Krome
    Mar 29 '10 at 4:21
  • 2
    All the libraries I know about are here: odata.org/developers/odata-sdk and the word on the street is that a few folks are doing a Ruby one. Mar 29 '10 at 7:02

This is completed, as


is an oData endpoint and we officially support it!


I emailed Jeff Atwood last night a one line email. "You should make a Stack Overflow API using OData." Then I realized that, as Linus says, Talk is Cheap, Show me the Code. So I created an initial prototype of a Stack Overflow API using OData on an airplane. I allocated the whole 12 hour flight. Unfortunately it took 30 minutes, so I watched movies the rest of the time.

Stack Overflow has always been incredibly open and generous with their data. I propose that an OData endpint would give us much more flexible access to their data than a custom XML and/or JSON API that they'll need be constantly rev'ing.

With a proprietary API, folks will rush to create Stack Overflow clients in many languages, but that work is already done with OData including libraries for iPhone, PHP and Java. There's a growing list of OData SDKs that could all be used to talk to a service like this. I could load it into Excel using PowerPivot if I like as well.

Also, this service could totally be extended beyond this simple GET example. You can do complete CRUD with OData, and it's not tied to .NET in anyway. TweetDeck for Stack Overflow perhaps?

I propose we encourage Stack Overflow to put more than the 30 minutes that I have put into it and make a proper OData service for their data, rather than a custom API. I volunteer to help. If not, we can do it ourselves with their dump data (perhaps weekly if they can step it up?) and a cloud instance.

  • 2
    Why do you believe the EDM serialization format that is used in the Atom entry better than a "custom XML" format? Is is because Microsoft are producing libraries/tools that know how to consume that format? Or do you believe that it is a format that can handle changes resiliently? Mar 29 '10 at 3:11
  • 1
    All of those things. Not just Microsoft...IBM has libraries as well. It puts the caller in control, not the API developer. Mar 29 '10 at 3:24
  • 3
    @Scott Hanselman : Can you also do versioning, Scott? so forexample .. what happens if the entities change (new properties added, deprecated properties dropped) ???
    – Pure.Krome
    Mar 29 '10 at 4:20
  • 3
    Until Jeff and crew publish a live data API, I'll try and keep a working OData reference available via this URL: stackunderwhelm.com Currently it points to Scott's implementation at Orcsweb. If that goes down I'll find or create an alternate as quickly as possible.
    – hemp
    Mar 29 '10 at 7:55
  • Thanks @Scott for the high level help on this one :), much appreciated. Mar 29 '10 at 11:43
  • 1
    @Scott Actually, using the EDM serialization format puts control completely in the hands of the WCF Data Services team. A single format is being forced on all OData services. Try using Windows Live Writer to post to an OData service. Atom pub allows it but OData doesn't. Try just posting even plain XML to an OData collection and it will fail. The content must follow the EDM format. Also, I am struggling to find docs on this format. These few paragraphs are all I can find odata.org/developers/protocols/atom-format#XMLRepresentations Mar 29 '10 at 12:58
  • 1
    @Darrel: it's actually a bit of both. Yes, the fact that we're building parsers for it certainly helps. Also I think it's a reasonable trade-off between free-form XML and something record-oriented that can be handled well by traditional databases. The format (and semantics behind it) also version well and can handle extra fields and such. Re: your second comment, what information is missing? We need to learn to articulate this well, so all feedback around the content in the site is good.
    – user145439
    Mar 29 '10 at 23:11
  • 1
    @Pablo I really wish it was possible to decouple the payload format from the service. That's what the Atom:Entry Type fields is for but you don't really use it. As I continue to go through the OData docs I am finding more information about the m: and d: namespaces but I find it is intermixed with discussion of other atom related issues. And while I have your attention :-) can you please embed a link to $Metadata in the feed? Mar 30 '10 at 1:28
  • hrm .. as of May 5 it appears Scott's Orcsweb-hosted example site has been taken down.
    – hemp
    May 5 '10 at 21:37
  • Has anyone put any thought to a pure ASP.NET MVC OData implementation?
    – Phil Peace
    Oct 8 '10 at 9:25

While OData is still relatively new, many other organizations are opening up their data using this format. I expect that some very interesting mashups can result from having SO data available to OData tools and clients.

  • 1
    Oh come on, you just want to make tons of money with stackoverflowoverflow.com.
    – balpha
    Mar 25 '10 at 16:25
  • @balpha - I wish! I need to get back to that. Auto-posting stuff is non-trivial on these sites though...
    – Pollyanna
    Mar 25 '10 at 17:23
  • 7
    Bam. Now we apply pressure... hanselman.com/blog/… Mar 28 '10 at 17:39

"Standard API?" It's yet another random Microsoft data access invention from precisely 15 minutes ago. Why not YQL?

  • 2
    Why openid....?
    – Pollyanna
    Mar 30 '10 at 15:27
  • 9
    Joel, you're just jealous because there's no OData library for Wasabi yet.
    – balpha
    Mar 30 '10 at 15:29
  • @Joel - You make a good point in terms of this actually becoming a standard... From what I've seen, oData is only going to grow and is very easy to integrate into an existing code base.
    – RSolberg
    Mar 30 '10 at 15:36
  • 1
    @Joel Spolsky, since I don't code in php (anymore), YQL is less attractive at the moment, I'd prefer OData (in a subjective way, I'm not considering what would be best for SO, because I can't do that without speculating). OData was also known as Astoria then ADONet DataServices, it's first appearances were around may 2007. channel9.msdn.com/posts/jeffsand/… Mar 30 '10 at 18:53
  • 4
    OData is based on AtomPub, which goes way back. And I think the YQL syntax, while interesting, is basically tunneling SQL through a querystring. Hacky. OData's RESTful URL's are a lot cleaner (e.g. Also, OData fits a lot better with ASP.NET MVC. I added OData support in to an MVC application, and it went very smoothly. Mar 31 '10 at 0:53

OData Away sirs:



On the one hand, it's based on AtomPub, and AtomPub is wicked cool.

On the other hand, it's junked up with a whole pile of data types that I don't particularly care to worry about... I mean, really - I'm sending back an integer and I gotta worry about whether the server is gonna choke if I mark it as Int32 instead of Int16? That's the sort of madness that made me hate SOAP!

I hate to sound like a MS basher, but this smells like yet another over-engineered spec in search of a purpose. And the rotten encoding of the documentation itself doesn't help ("“raw†format"?!)

  • 1
    If the XML is to heavy for you, take a look at the JSON. It's pretty clean:$format=json I think you're conflating things a little - the datatypes are being sent to you, you're not supplying them. If you (or a programming library) needs them, they're available. If not, ignore them. Mar 31 '10 at 17:00
  • 1
    @Jon: if it actually works that way, I'm cool with it. It's bad experiences with the .NET SOAP libraries (motto: when in doubt, fail spectacularly) that have made me suspicious - I'm all for extra information when it IS actually needed, but the mere existence of Int16 in a text-based data-exchange format makes me uneasy... On the bright side though, fixed-width strings appear to be absent!
    – Shog9
    May 4 '10 at 3:40

The Stack Exchange Data Explorer (SEDE) includes OData endpoints as well as the ability to name and save queries so that other people can view the results. Please note that the data explorer uses the monthly data dumps and is hosted offsite in Azure to prevent performance issues with the production database. This means the only way to access real-time data is to use the Stack Apps API.

See the Data Explorer FAQ or this meta question for more information.


Let the "change" happen to move to OData. It really seems sweet (from @shanselman's blog post), and I can't wait to get my hands on it.

Hopefully a StackOverflowDeck or a StackOverFlowy built on Stack Overflow OData, will come along pretty soon.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .