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.

While it is a step in the right direction, the /sites return is missing a vital component: a key field.

All of the data currently in /sites is the arbitrary data that can change.

We need a constant to use as a key for any cached data.

The key may be an arbitrary value. I suggest, as a general rule, the initials of the site.

e.g.

  • so
  • mso
  • su
  • sf
  • sa

Also: can you please add the association_id as a root member of the /users/{id}/associated result so that these can be stored in a list.

EDIT: Something that I neglected to highlight previously, and the source for my suggested values, is that someone at Stack Overflow seems to think that a 'key-friendly' id has some value; Consider the static resources urls:

{
  "api_sites": [
    {
      "name": "Stack Overflow",
      "logo_url": "http://sstatic.net/so/img/logo.png",
    },
    {
      "name": "Server Fault",
      "logo_url": "http://sstatic.net/sf/img/logo.png",
    },
    {
      "name": "Super User",
      "logo_url": "http://sstatic.net/su/img/logo.png",
    },
    {
      "name": "Stack Overflow Meta",
      "logo_url": "http://sstatic.net/mso/img/logo.png",
    },
    {
      "name": "Stack Apps",
      "logo_url": "http://sstatic.net/sa/img/logo.png",
    }
  ]
}

But in the interest of flexibility, I am simply adding a read-only id property to my Site domain class that returns the name lcased with whitespace removed. If the name is guaranteed to be unique, barring any bizarre name variants, this should sufficiently serve as a key.

I have also intercepted the deserialization of /users/{id}/associated and introduced a root level id member to hold the association id.

share|improve this question
1  
+1 Took my head a second to wrap around this, but I see where variable data could break sites down the road. Good suggestion. –  Nathan Osman Jun 16 '10 at 1:24
1  
I anticipate people saying that the site_url is unique. Do you want to use a url as a key? var site = sites["sa"] or var site = sites["http://stackapps.com"]; - you choose. ;-) –  Sky Sanders Jun 16 '10 at 1:44
2  
+1 - totally needed. Whilst a URL changing would be rare, it's not impossible. Same goes for the changing of the site name. –  Mark Henderson Jun 16 '10 at 1:49
2  
+1 Needed and vital, i got your point when i started to play with stackauth. –  systempuntoout Jul 12 '10 at 10:39
    
It's not rare any more with SE 2.0 with sites coming out of private beta. –  Lucas Jones Jul 12 '10 at 16:54
    
Sounds like a non-problem to me. I've been using site name with no problems - it's both cache-friendly and SEO friendly. And besides, it's cache. So what if you have a cache miss? Example of a cached request + URL: stacktagz.com/#/stackoverflow.com/22656/jon-skeet –  Igor Zevaka Jul 13 '10 at 6:41
add comment

4 Answers

up vote 4 down vote accepted

bump

I've just delved into the stackauth methods for the first time today, and I can't help but notice that there's no real URL friendly key exposed.

For example, I want a unique URL for each API endpoint in my app, so that it can be bookmarked. E.g. http://www.column80.com/?site=stackoverflow

But none of the keys provided are any good. name has spaces (who wants a %20 in their URL?). site_url is even worse for including in a URL (it contains http:// etc), and you haven't specified that the index is reliable (and even if it were, http://www.column80.com/?site=1 doesn't mean anything to anyone, especially not if you want to do SEO in the future - and it means doing a for x=... loop instead of a for each loop).

So my only option at the moment is to roll my own, which is

  1. Annoying
  2. Unreliable
  3. Slow(er than it has to be)

A unique key would fix that, because keys can be descriptive, and generally don't contain spaces, and even a 3-letter (mso etc) key is more descriptive than 1

Update

See this meta question here. It would appear that site_name is in fact very likely to change. I know these are edge-cases for initial launch/beta sites, but the fact still remains...

Also, as I suspected, the index is not a reliable key. The two new sites have been inserted as keys 4 and 5, bumping stackapps up to 6. Which means that if someone had bookmarked http://sa.column80.com/?api=4 for StackApps, today they would be receiving Web Apps quite unexpectedly. I know that this is because of my poor design, but I think I've made it fairly clear that there's no real way around this.

share|improve this answer
    
sorry if it seems naive but, could you just extract the second level domain from url with regex using it as a key? –  systempuntoout Jun 25 '10 at 9:02
1  
@system - sure, but then to find the associated record in the StackAuth list you have to do serial search to find it, and then you could get multiple matches (what if they launch two sites on the same 2nd level domain? Liiikee... area51.stackexchange.com and odata.stackexchange.com) - it's just not unique enough. –  Mark Henderson Jun 25 '10 at 9:25
    
sure, your regex should handle this case taking third\forth\etc. levels domain into account. (area51.stackexchange , odata.stackexchange would be your keys) Something like : ^http://(.*)\.com$ –  systempuntoout Jun 25 '10 at 10:18
    
as noted in the question update, I am simply adding a read-only id property to my Site domain class that returns the name lcased with whitespace removed. If the name is guaranteed to be unique, barring any bizarre name variants, this should sufficiently serve as a key. –  Sky Sanders Jun 27 '10 at 17:56
    
@Code, thanks - pity we have to work around these things by wrapping a wrapper, but oh well. –  Mark Henderson Jun 27 '10 at 23:52
add comment

It looks like we now have api_site_parameter. This seems like a reasonable thing to use.

share|improve this answer
    
I'm not sure if this was available when the question was asked, but it seems like a good solution. –  Gelatin Jan 1 at 0:38
add comment

BUMP:

Although this request seems sealed with a status-declined flag..

i started to play with Stackauth and i have to say that what requested in this post is more than proper and reasonable.

Using /sites i had to craft an utility method that strips the domains from site_urls using regex (^http://(.*).com$ ), adding them to the data structure as keys.

The resulting data is something like this:

{
  "api_sites": [
    {"stackoverflow":{
      "name": "Stack Overflow",
      "logo_url": "http://sstatic.net/so/img/logo.png",
      "api_endpoint": "http://api.stackoverflow.com",
      "site_url": "http://stackoverflow.com",
      "description": "Q&A for professional and enthusiast programmers",
      "icon_url": "http://sstatic.net/so/apple-touch-icon.png",
      "state": "normal",
      "styling": {
        "link_color": "#0077CC",
        "tag_foreground_color": "#3E6D8E",
        "tag_background_color": "#E0EAF1"
      }
    },
    "serverfault":{
      "name": "Server Fault",
      "logo_url": "http://sstatic.net/sf/img/logo.png",
      "api_endpoint": "http://api.serverfault.com",
      "site_url": "http://serverfault.com",
      "description": "Q&A for system administrators and IT professionals",
      "icon_url": "http://sstatic.net/sf/apple-touch-icon.png",
      "state": "normal",
      "styling": {
        "link_color": "#10456A",
        "tag_foreground_color": "#444444",
        "tag_background_color": "#F3F1D9"
      }
    },
    .....
    "cooking.stackexchange":{
      "name": "Cooking",
      "logo_url": "http://sstatic.net/cooking/img/logo.png",
      "api_endpoint": "http://api.cooking.stackexchange.com",
      "site_url": "http://cooking.stackexchange.com",
      "description": "Q&A for food and cooking",
      "icon_url": "http://sstatic.net/cooking/apple-touch-icon.png",
      "state": "closed_beta",
      "styling": {
        "link_color": "#0077CC",
        "tag_foreground_color": "#FFF",
        "tag_background_color": "#FFF"
      }
    },
    "meta.cooking.stackexchange":{
      "name": "Cooking Meta",
      "logo_url": "http://sstatic.net/cookingmeta/img/logo.png",
      "api_endpoint": "http://api.meta.cooking.stackexchange.com",
      "site_url": "http://meta.cooking.stackexchange.com",
      "description": "Q&A about the cooking site",
      "icon_url": "http://sstatic.net/cookingmeta/apple-touch-icon.png",
      "state": "linked_meta",
      "styling": {
        "link_color": "#3D3D3D",
        "tag_foreground_color": "#666666",
        "tag_background_color": "#FFF"
      }
    ,....}]
}

It works and i can use this data structure in my code, but it is slow and unreliable.
I vote with two raised hands that a meaningful key should be added to the response.

share|improve this answer
3  
uhm, do you mind explaining the downvote? thanks –  systempuntoout Jul 12 '10 at 12:17
2  
+100000 You get an upvote from me for this. –  Nathan Osman Jul 19 '10 at 1:30
add comment

name is guaranteed to be constant. So is site_url*.

Use one of them.

/users/{id}/associated is not vectorized (as a part of stackauth and not api.* it doesn't follow the "all {id}'s are vectors" rule) and thus you should be able to keep track of that information yourself easily.

*There might be some goofiness with area51 created sites in this regard, we'll keep you posted when the details shake out.


Update.

The proper way** to lookup site data is to key off of the current domain (http://stackoverflow.com, for instance, site_url basically) and resolve old/cached entries using aliases.

Its probably going to be months from now before any site returns anything in aliases - whenever WebApps becomes... not WebApps, assuming it ever does - buts its spec'd.

**As opposed to synthesizing some "key" and trying to hold it constant in the face of changing site data. Pro-tip, this is how the SO engine works!

share|improve this answer
    
So... What will happen if you choose an innocent sounding name and Nissan sue the shit out of you and you decide you need to change the site name because you've unknowingly breached their trademark? –  Mark Henderson Jun 16 '10 at 13:39
    
@Farseeker - That's awfully unlikely. For one, we take strides not to create sites that are obviously trademark infringing, and what makes you think an abbreviation widely known on the internet to mean "Nissan blah blah" would be safe from such a suit anyway? –  Kevin Montrose Jun 16 '10 at 14:06
    
If you're not familiar with Nissan v Nissan, back when Nissan was called Datsun a guy who's surname was Nissan registered Nissan.com - then Datsun changed their name TO Nissan and have been suing the guy for about the last 15 years to get his domain name. Sounds absurd, but it happens. Just sayin... –  Mark Henderson Jun 16 '10 at 14:15
    
-1 I will defer on the site key for now. The association id is another story. There is no key at all in the results of users/id/associated. if a resource requires a key to acquire the key should be a component of the resource. –  Sky Sanders Jun 16 '10 at 18:19
1  
your decision to omit/not include the id from the result seems arbitrary. if you can explain your position rather than dismissing the request as unnecessary we might be able to have a dialog. as it is, i am just a bit offended. –  Sky Sanders Jun 16 '10 at 18:25
    
@code poet - ... you obviously already know the association_id, as you passed it to the method. The only reason members of {id} are returned in "proper" api methods is because {id} is vectorized, and thus the returned objects are ambiguously associated without an id field. Why return redundant information? –  Kevin Montrose Jun 16 '10 at 19:17
1  
@Kevin I don't like it and i don't think that something like stackoverflow.com can be key-friendly, url-friendly or seo-friendly. Please keep in mind that there are apps using these "keys" as parameter on Urls (like mine or column 80). –  systempuntoout Jul 12 '10 at 13:07
    
@systempuntoout - I fail to see how an integer or an opaque string is more SEO-friendly, whatever that means. I also fail to see how keying off a string is arduous. If you're not concerned about cache-ing over "site graduates from beta" periods of time, you can use name just as well as site_url - heck, you could use description if you wanted, that's unlikely to change frequently. –  Kevin Montrose Jul 12 '10 at 14:11
    
@Kevin if you look at my example, i'm not using an opaque string or an integer but simply the domain without the first level. Name and site_url are ugly keywords. Imho you are not carefully thinking how these keys will be used, expecially on web applications. Have a look at Farseeker post, you are suggesting him to adopt a solution like "column80.com/?site=Q&A for professional and enthusiast programmers !" –  systempuntoout Jul 12 '10 at 14:38
    
@systempuntoout - the description suggestion was in jest. You could always, you know, not expose that particular detail to users directly in the url... Though I don't really see the problem with doing what you're doing, just stripping http:// off of site_url. –  Kevin Montrose Jul 12 '10 at 14:48
1  
@Kevin as i said in my BUMP answer, my solution is working but i'm forced to do extraparsing that, in my opinion, could be avoidable. –  systempuntoout Jul 13 '10 at 12:51
    
@systempuntoout - So what you're saying is that the API provides exactly what you need to make a workable solution, but it has to be manipulated somewhat. The API will not be custom tailored to any particular [app] or even class of [app]. –  Kevin Montrose Jul 13 '10 at 15:39
2  
@Kevin that's what YOU are saying, not me :D! We are not asking any custom tailored feature here, c'mon. Anyway, i give up ;). –  systempuntoout Jul 13 '10 at 15:49
add comment

You must log in to answer this question.

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