2

So today I decided to continue refining my JavaScript skills (different post over on Code Review SE if you'd like to review the results) and utilized the Stack Exchange API (v2.2) to write a "user flair" replica.

In case you don't know what the flair that SE provides is:

profile for PerpetualJ on Stack Exchange, a network of free, community-driven Q&A sites

The process was a little tedious in places, but only because I am still learning the concept of callbacks in JavaScript. Overall though, I believe they turned out pretty decent (only two shown here).

Wheel Box

This got me thinking, in my testing I had to make several separate calls to get all of the information I needed to replicate the flair, but used two primary methods:

Do the future plans for the API include a "user flair" call that would give all of the following information for building custom user flair cards:

  • Most Common Display Name or First Encountered
    • I say most common or first encountered because your display name can be different on each SE network.
  • Total Reputation
  • Total Number of Badges (Gold, Silver, and Bronze)
  • Link to SE Network Profile
  • SE Network Profile Image URL
    • This is because your profile image can be different on each SE network.
    • Could use the display name here for the above to prevent the multiple networks since all users have to set their SE Network profile to match an existing sub-site, so could be considered the preferred account information.
  • Top 10 Sites (or as many as possible up to this)
    • Ordered by reputation descending.
    • Reputation per site.
    • Badge Counts per site (Gold, Silver, and Bronze)
    • Link to Profile on Site

My biggest concern is that it would be underutilized and eventually fall out of support. Perhaps this is why it doesn't exist already?

1 Answer 1

2

A unified call would be nice, but everything you asked for falls into one of 3 categories:

  1. It's already in the users/{ids}/associated call.

  2. It's trivially easy to calculate in the app or script. EG: Total reputation and total badges.

  3. Or, it's the kind of information that changes very slowly and should be heavily cached by your app/script for at least a day.

    So the first time you see a user-id, you have to make a few extra calls, but after that your app can, and should, pull that data from its own storage.
    Just update it if it's more than a day old, or better yet, only if the user explicitly requests it. (For most users, their non-numerical flair data is unchanged for years at a time.)

You must log in to answer this question.

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