Skip to main content
replaced http://stackoverflow.com/ with https://stackoverflow.com/
Source Link

Its probably easiest to think of this route as a view onto a users reputation graphreputation graph.

+/- a user's questions/answers is returned, but the on_date is intentionally ambiguous. on_date ends up being the last voting event that occurred in a collapsed group. All votes on a post in a given period our collapsed based on post_id. No indication is given as to when any vote but the last one was made, nor whether it was an up or down vote.

user_id is returned because the route is vectorized, in that use-case you need to be able to map a returned value back to a user.

The key on the results (once de-vectorized, for lack of a better word) is the post_id. Though for caching purposes, you probably want to key on the [post_id, on_date]-tuple, with a caveat.

That caveat is that since the underlying votes are collapsed into [on_date, post_id]-tuples based on the queried window, you have to be aware of that window when updating your cache.


Be aware that depending on how you're using this data, conceptually, there's no guarantee that post_id is unique in the stream.

Its probably easiest to think of this route as a view onto a users reputation graph.

+/- a user's questions/answers is returned, but the on_date is intentionally ambiguous. on_date ends up being the last voting event that occurred in a collapsed group. All votes on a post in a given period our collapsed based on post_id. No indication is given as to when any vote but the last one was made, nor whether it was an up or down vote.

user_id is returned because the route is vectorized, in that use-case you need to be able to map a returned value back to a user.

The key on the results (once de-vectorized, for lack of a better word) is the post_id. Though for caching purposes, you probably want to key on the [post_id, on_date]-tuple, with a caveat.

That caveat is that since the underlying votes are collapsed into [on_date, post_id]-tuples based on the queried window, you have to be aware of that window when updating your cache.


Be aware that depending on how you're using this data, conceptually, there's no guarantee that post_id is unique in the stream.

Its probably easiest to think of this route as a view onto a users reputation graph.

+/- a user's questions/answers is returned, but the on_date is intentionally ambiguous. on_date ends up being the last voting event that occurred in a collapsed group. All votes on a post in a given period our collapsed based on post_id. No indication is given as to when any vote but the last one was made, nor whether it was an up or down vote.

user_id is returned because the route is vectorized, in that use-case you need to be able to map a returned value back to a user.

The key on the results (once de-vectorized, for lack of a better word) is the post_id. Though for caching purposes, you probably want to key on the [post_id, on_date]-tuple, with a caveat.

That caveat is that since the underlying votes are collapsed into [on_date, post_id]-tuples based on the queried window, you have to be aware of that window when updating your cache.


Be aware that depending on how you're using this data, conceptually, there's no guarantee that post_id is unique in the stream.

Source Link
Kevin Montrose
  • 18.7k
  • 6
  • 35
  • 62

Its probably easiest to think of this route as a view onto a users reputation graph.

+/- a user's questions/answers is returned, but the on_date is intentionally ambiguous. on_date ends up being the last voting event that occurred in a collapsed group. All votes on a post in a given period our collapsed based on post_id. No indication is given as to when any vote but the last one was made, nor whether it was an up or down vote.

user_id is returned because the route is vectorized, in that use-case you need to be able to map a returned value back to a user.

The key on the results (once de-vectorized, for lack of a better word) is the post_id. Though for caching purposes, you probably want to key on the [post_id, on_date]-tuple, with a caveat.

That caveat is that since the underlying votes are collapsed into [on_date, post_id]-tuples based on the queried window, you have to be aware of that window when updating your cache.


Be aware that depending on how you're using this data, conceptually, there's no guarantee that post_id is unique in the stream.