Inconsistency in the flairlist api with respect to other APIs #270

bboe opened this Issue Dec 2, 2011 · 0 comments


None yet

1 participant


I don't know what the exact reddit terminology is, but here goes: The flairlist api, /r/<community>/api/flairlist is similar to the submissions api /r/<community>/.json and comments api, /<community>/r/comments/<id>/.json in that it only returns a finite number of results on each call. Similar to both submissions and comments, flairlist subsequent results can be fetched by passing an appropriate valued after parameter.

I just added support in the reddit_api module for grabbing flairlists. If you look at the last three arguments to the _get_content function, root_field, thing_field, after_field, you may notice that I had to special case these items for the flairlist api.

The reason for this is because both the comment and submission api return data like so:

{'data' : {'children' : [...], 'after' : 'someid'}}

whereas the flairlist api returns data like so:

{'users' : [...], 'next' : 'someid'}

There are three discrepancies here:

  1. There is no exterior data encapsulation in the flairlist result.
  2. The key pertaining to the list differs: children v. users
  3. The key pertaining to the after element differs: after v. next (particularly interesting because the url parameter after works in both cases)

Aside from these three inconsistencies, there is also the inconsistency of not returning the defined types as is done with comments and submissions. What I mean is that the user objects returned by the flairlist api are simply usernames whereas in both the comment and submission APIs they represent an object with an id and a username.

Finally, I would like to add that I'm not complaining. I think having these APIs are great, though I think they could be improved by making them consistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment