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",
}
]
}
So,But in SOAPI, this is the valueinterest of flexibility, I am hardcoding as idsimply adding a read-only id property to my Site domain class that returns the name lcased with whitespace removed. If new sites are introduced between builds, the name is guaranteed to be unique, barring any bizarre name variants, lowercased with spaces removed will be usedthis 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.
