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.

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

4 Answers 4

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.

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

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

12
  • @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? Jun 16, 2010 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... Jun 16, 2010 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. Jun 16, 2010 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. Jun 16, 2010 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? Jun 16, 2010 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). Jul 12, 2010 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. Jul 12, 2010 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 !" Jul 12, 2010 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. Jul 12, 2010 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. Jul 13, 2010 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]. Jul 13, 2010 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 ;). Jul 13, 2010 at 15:49
0

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

1
  • I'm not sure if this was available when the question was asked, but it seems like a good solution.
    – Gelatin
    Jan 1, 2014 at 0:38

You must log in to answer this question.

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