7

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.

Improve this question
4
  • 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. ;-) Commented Jun 16, 2010 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. Commented Jun 16, 2010 at 1:49
  • It's not rare any more with SE 2.0 with sites coming out of private beta. Commented Jul 12, 2010 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 Commented Jul 13, 2010 at 6:41

4 Answers 4

Reset to default
4

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.

Improve this answer

5 Comments

sorry if it seems naive but, could you just extract the second level domain from url with regex using it as a key?
@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.
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$
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.
@Code, thanks - pity we have to work around these things by wrapping a wrapper, but oh well.
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.

Improve this answer

Comments

0

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!

Improve this answer

12 Comments

@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?
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.
@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).
@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.
@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 ;).
|
0

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

Improve this answer

1 Comment

I'm not sure if this was available when the question was asked, but it seems like a good solution.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.