please add a key fields to stackauth results

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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!}

Answer 4

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