One of the more popular meta topics is Implement OData API for StackOverflow

Well ... done, here you go http://data.stackexchange.com its an odata endpoint for the current stack overflow db.

But this does leave me really confused...

  1. Are people wanting "live" up-to-date data from these endpoints? (as an alternative to the API)

  2. Are people wanting "write" support?

  3. Great, you can access the SO db via LinqPad but now what, the odata interfaces will not perform as well as a direct query on data explorer and operations like join / count / having or temp tables are not available. Things like a rich full text search are also not exposed (since azure supports no full text indexing)

Is there any value in having a one month old odata endpoint out there?

  • I'm writing a stack app from the API that really needs an easy way to query data; with the current API I've got to do a lot of meaty querying myself after grabbing the JSON data. I was hoping there would be a Stack OVerflow OData endpoint because it'd be easier to query against that than the current API. So yes, there is a need for it; but if it's not 'live', then I can do it myself and get the same result. If Jeff and Co. could implement an OData API, it'd help those apps that need to query live data to be useful. – George Stocker May 30 '10 at 3:07
  • @George, so an up to 1 month old odata endpoint is of no use to you? Also keep in mind data explorer already has a "submit sql" get json end point, which is much richer than odata anyway. – waffles May 30 '10 at 6:01

Well, one of the reasons we're doing the Data Explorer is to meet the needs of those people who want an OData interface -- the Data Explorer should also be an oData endpoint, hence:


The reason our API at http://stackapps.com isn't oData:

  1. We had already started on the API before anyone approached us about oData, so it was too late.

  2. oData supports completely arbitrary queries of any type (it's basically raw-SQL-in-another-form), which we're not going to allow on our production database. Send three or four monster bad queries through, and you could bring the production websites to their knees, interrupting service for everyone. That's why this arbitrary query stuff has to be done in the cloud against the data dumps.

  3. I don't believe a "one size fits all, generic API" is actually a good strategy for a site of our size. There's a reason people build custom software to better solve specific problems, rather than building everything on Sharepoint or Drupal or WordPress or whatever.

| improve this answer | |
  • 2
    Odata doesn't allow "arbitrary queries of any kind" over your database. There's a layer inbetween (your model) where you can contrain the queries, choose to expose only a subset of your data, or even expose things which are not even stored in your database. OData is a really good fit if you have tons of data which you want exposed, especially since it is standardized, it enables lots of clients which out of the box can work with your data, instead of relying on 3rd party conversion software. For custom AI functions (post question, add vote, etc) webservices are better. – Toad May 30 '10 at 4:23
  • one of the bigger questions here is ... is an odata interface that is up to 1 month old really of any use to anyone? If you want to do hard core analytics you resort to SQL anyway, and we kind of expose a SQL -> JSON endpoints for data explorer to run queries. odata offers a subset of SQL, its leaky abstraction between your DB and you JSON endpoints which imho feels more complex than SQL anyway. kentbrewster.com/netflix-odata – waffles May 30 '10 at 6:07
  • @waffles um, yes, considering there's like TWENTY MONTHS worth of data you can analyze via oData. If you absolutely, positively just gotta have that last 1-30 days, then use the API. – Jeff Atwood May 30 '10 at 6:54

You must log in to answer this question.

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