4

I know you wanted to reduce the amount of data returned, but hasn't it gone a little far? Especially as there are no numerical site IDs. For example the Apple site is now called AskDifferent, however the API returns in both stackauth routes that the name is Apple.

It means that the site names can change, it would be more useful to have site URL rather than site name, even though that would increase requests, because if you were displaying a list of associated sites then you'd need to go a request the site name from every single site.

Also with reputation, [many] apps show global reputation, that is now much harder, as a request has to be made to every single site to get the user's reputation.

Plus the reason for the reduction in information is to save bandwidth, yet the /sites route has increased in size. And the associated route, returns the associaton_id for each site; this is exactly the same for each site, and the association_id is part of the request, so the app will already know it.

I know we can still use 1.0, but 1.1 is the direction the API is heading right? So when 2.0 and 3.0 come along we'll be left with the 1.1 route.

In total, I'm asking for the reputation and site url to be added to the /associated route.

1
  • 1
    Why was the reputation data removed from the associated accounts list? Commented Feb 13, 2011 at 2:26

1 Answer 1

1

Unfortunately, there are no performance savings to be had if reputation is returned; this is simple the way the Stack Exchange network works at the moment.

I will say that I'm hoping that by API 2.0 it will have become much cheaper to lookup associated user details, if so reputation will certainly be back in the 2.0 timeframe as a default.

If it remains expensive, it will probably be made available as an optional return. But for now, since 1.0 is guaranteed to live as long as 1.1, the two routes (/1.0/users/... and /1.1/users/...) are distinct for simplicity's sake.

8
  • @Kevin, please explain how I am meant to calculate global reputation, using the 1.1 API.
    – Jonathan.
    Commented Feb 13, 2011 at 10:13
  • @Jonathan: Either issue requests to each site or use v1.0. Commented Feb 14, 2011 at 0:20
  • @George this is what I thought, so it means making 14 requests if the user has 13 accounts (for example). This doesn't sound pike saving bandwidth. And currently the identification of sites is very flimsy. Its like if the API only let you get questions from their title and there was no IDs for questions.
    – Jonathan.
    Commented Feb 14, 2011 at 0:29
  • @Kevin the stackauth 1.1 methods are a step backward from 1.0. Hopefully 1.0 on stackauth will never be gotten rid of. On the other hand te rest of 1.1 is fantastic.
    – Jonathan.
    Commented Feb 14, 2011 at 0:32
  • @Jonathan - 1.0 is guaranteed to live for the duration of 1.1. Its in the announcement. Commented Feb 14, 2011 at 0:38
  • @Kevin, I know I've read it, just saying when both 1.x are superseded, will the 1.0 still be around?
    – Jonathan.
    Commented Feb 14, 2011 at 8:05
  • @Jonathan - for a while probably, but your supposition that 1.1 somehow limits what can be be 2.0 is wrong and that's the fundamental disconnect. Commented Feb 14, 2011 at 16:42
  • @Kevin, Sorry i don't understand your last sentence. For now I'll keep using 1.0 and bring this up again when we get to 2.0. But please tell me why the association id is returned in the response?
    – Jonathan.
    Commented Feb 14, 2011 at 16:57

You must log in to answer this question.

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