Take the 2-minute tour ×
Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.

It would seem to me that a simple API that return an array of the API base URL and perhaps the common name of the sites that support the API would be valuable. Is this sensible?

EDIT:

This is what I want:

{
  "api" : [
    { "endpoint" : "api.stackoverflow.com",
      "name" : "StackOverflow"},
    { "endpoint" : "api.meta.stackoverflow.com",
      "name" : "Meta"},
    { "endpoint" : "api.SuperUser.com",
      "name" : "SuperUser"},
    { "endpoint" : "api.bobsyouruncle.com",
      "name" : "Bob's your Uncle SE"}
   ]
}
share|improve this question
    
Why not just store a dictionary in your application, internally, which contains this information. You can update this manually for the time being, then once this feature becomes available you can just create a simple retrieve function to fill your dictionary? It's what I'm doing currently and it works quite well! –  JonB May 30 '10 at 21:29
1  
@JonB the stackoverflow.net wrapper has this and that is what I am using and it is fine until the SE floodgates are opened :) –  TheHurt May 30 '10 at 21:41
    
Yeah, it's what I decided to do in my Obj-c stuff. –  JonB May 30 '10 at 22:07

3 Answers 3

up vote 9 down vote accepted

I agree that there needs to be a way to discover API endpoints. Especially with the brave new world of SE 2.0 potentially leading to an ever increasing number of API-ified sites out there.

However, there isn't a good place to shove this functionality just yet.

Currently, we only have two places it could go:

  • api.[stackoverflow|superuser|serverfault|meta.stackoverflow].com
    • not "global," and accordingly shouldn't know about all the other sites in the network
  • api.stackapps.com
    • more "global," than the above, but also a site onto itself; it'd be a weird one-off to also have it serve up a network map

A similar problem exists with getting user associated accounts.

In short, once there is a place for this data to come from it'll be made available. Most likely, this will exist "out of band" from the regular API.


See StackAuth - /sites route - for endpoint discovery.

share|improve this answer
1  
+1 - this scenario has been implemented via the StackAuth routes in the meantime as (implicitly) documented here for example, so thanks for that! Shouldn't the status be changed from deferred to completed then? For the record, I'd personally preferred it to be http://api.stackexchange.com for consistency with other special sites within the Stack Exchange network (like area51, odata, etc.) rather than an entirely new out of band site, but alas, that's mostly a subjective matter ... –  Steffen Opel Jul 6 '10 at 21:16
    
I can't edit posts yet, so here is the correct link for StackAuth 1.0 API: stackauth.com/1.0/help –  Greg Bray Jul 16 '10 at 18:44
    
@Greg - fixed it. –  Kevin Montrose Jul 16 '10 at 18:49

Kevin hinted at something like this when I was discussing making a FUSE (file system in userspace) implementation of the API on dev.meta.

It would work like this, assuming you had the file system mounted on /stacks :

cat /stacks/stackoverflow.com/users/1/reputation

... You'd see Jeff's reputation. The problem is (and was) is that I'd need to be able to discover all API methods to organize and set up the FS hierarchy, which means some method to discover all available methods and hints as to what they return.

The particular question went to radio silence, I'm not sure if something like that made it into the current beta, but I hope it does :) A FUSE implementation would let lots and lots of languages for where no API bindings exist access the API rather easily.

Edit

There is a help option , but its not quite convenient to parse.

share|improve this answer
    
Welcome to StackApps, @Tim! –  Nathan Osman May 20 '10 at 6:59
    
regex? '<a href="/0.8/help/[^"]+">([^<]+)</a>' :D –  YOU May 20 '10 at 7:59
    
I guess I wasn't clear, I would like the ability to discover which SITES support the API. Not so important with just SOFU, but I think it will become important with SE 2.0, which I am under the assumption (maybe incorrectly) that the many SE sites will support the API as well. Method discovery is not what I am interested in. –  TheHurt May 20 '10 at 16:32

This is important if you want to be able to build an app that supports all available sites. Right now there are only a few, but eventually the list will grow and simply adding entries by hand will become too difficult. There also was a similar request for discovering what versions of the API are available.

The tricky part is that the methods would not really fit well on the API for any of the real "content" sites, but instead would be a better fit for a special StackExchange API or a StackApps API. Any /Sites or /Versions methods could then be separated from the general API methods that are accessible from the content sites APIs.

In the future there could be other app-specific methods that are added such as key management or retrieving stats for your application (unique IPs, request count, etc). These all should be grouped in one place, which doesn't really have a home right now.

I think the best thing to do right now is to setup your App to bind to a hard coded JSON object that you create so that you are ready once such a method is available. Also some of the API Library and Wrappers already try and help manage the available sites to query, currently using hard coded enumerators but eventual could bind to an API method.

share|improve this answer

You must log in to answer this question.

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